I am building Web API with ASP.NET Core hosted on IIS that will act as proxy integrating a few services.
I need to forward user credentials/identity to specific services managed by my API and to do so i want to enable ticket forwarding in Kerberos.
What steps i need to take to make it work?
First of all I need to setup my service as trusted in KDC and after that should it will received forwardable tickets instead of regular ones (i need to specific services that my API can forwards tickets to), am i right?
How do i then forward that ticket to other service using HttpClient?
Does attaching received token to request will be enough?
Am i correct about listed by me steps and is there any thing more to do?
Thank you all for help.
Related
I have a ASP.Net WebAPI service that is used by my AngularJS front end and I am making use of Owin and bearer token.
Now there is a need that we need to install an agent on the few of the client machines (developed in .Net core mostly) that is able to connect to our application and make similar calls. I can create a separate controller for this need, but want to host it in the same website.
How can I create a secure connection between this agent and the ASP.Net server hosted on Azure?
Currently I am looking at generating a Token during the agent installation based on the client MAC address and giving it with each call, but I am checking if there are any better way to address this need.
Any help in this direction is welcome.
Regards
Kiran
It seems that you’d like to enable only valid “agents” that installed on the client machines to communicate with your server, if that is the case, Azure AD provides Native Application to Web API authentication scenario (a native application that runs on a phone, tablet, or PC needs to authenticate a user to get resources from a web API that is secured by Azure AD), you could refer to it.
We currently have a node web server that does authentication of users including oauth2 to google and facebook. We would like for it to handle the serving of web pages while a stateless .NET web api handles the serving of the actual data (which is all requested asynchronously). My question is how to handle authentication to the web api?
I mean should the client even authenticate to the api (and if so how do we do the pass through authentication so that it is authenticated to both once authenticating against the web server) or should the web server authenticate the user and then just forward all api requests to the api along with a user id? What is the standard scheme used for this?
Thanks in advance.
This answer is late, but I'll post my thoughts for the heck of it. I would place a dummy api in your node app, just a simple pass-through for everything that is in your data api (the .net one). Then I'd lock down the data api so only your node server can talk to it. The short answer is that any api that you expose to the internet has to be locked down. If you do the above, you don't have to expose your data api to the internet. You get the added benefit of not having to deal with CORS - you can have a simple /api folder hanging off of your domain. You can also use this pass-through api to aggregate calls to multiple business apis if your solution ever grows. It's a very scalable architecture.
If you don't want to do the above, then you'll need to either place the data api on the same domain as the other site, or setup CORS so javascript/AJAX from one can call into the other. Once your data api can see cookies written by the other site, you'll need to authenticate them, probably very manually, in your .net api, since .net didn't write the auth cookie - node did.
We are building our public facing website on Wordpress and on a Linux server. The user will be logging into the WordPress site with OAuth2. Our data and API is going to be built on an ASP.net MVC4 server. I have a couple of problems that I need to resolve and am trying to figure out the most secure way to Authenticate on the IIS server.
1. I need to authenticate with Wordpress.
2. I need to associate customer numbers to the login from 1 above.
3. Somehow I need to then be able to use that associated customer number and some for of Authentication to allow the IIS server to service the requested API.
Some thoughts were to store some kind of UUID for each customer number and store it on the WP and IIS server and then when the request comes in to IIS confirm that the passed UUID matches what was issued to the WP server in step 2 above. My concern is though that this UUID could be compromised/forged at a later time and that UUID could be used to make calls to the API on the IIS server.
What is the best way to implement security on the IIS server that allows the customer to login only on the Wordpress server?
I'm currently using a Custom Http Authentication Module in IIS, so when I need to consume the web api from WP, I follow this approach: I build petition with my custom authentication rules (example: you can use a custom http header, o something else to pass credentials), in web api side, I check credentials (using http authentication module, of course), if everything is fine, http authentication module allow requests, if not, It deny request.
We have built a WCF service for an application and everything is working out well, using WSHttpBinding. We now have been asked to make sure the communication between the Web Application -> WCF -> Database is secure and have been asked to use SSL. Along with that they are requesting we make sure the WCF service can not be accessed by another application.
If we setup SSL, does that block others from trying to get in, or we do still need to setup the clientCredentialType setting on the service? Also the entire application (site, wcf, db) will be within a company's network, so if we setup the clientCredentialType="Windows" which account is used, how does WCF know to allow the website to talk to it, which Windows account are they using, or this an account we need to setup?
Thanks.
SSL has nothing to do with Authentication or Authorization.
It does 2 things:
prevents third parties from intercepting your traffic.
verifies that people are who they say they are.
The requirement "make sure the WCF service can not be accessed by another application" needs to be handled through some Authentication / Authorization mechanism. You could use Basic or Windows depending on your needs.
Since you're in the company's network, I'd attempt to use Windows Authentication. This will force clients to be authenticated through your domain, however it looks like you don't want just any domain user to have access. In this case, you need to set up either Role based authorization, or user based. Either war, you can drop a Web.config file into the same folder as the WCF service endpoint specifying what accounts are authorized. Other users will see a 401 Unauthorized.
This is the general approach I'd take.
I am trying to do something like this:
I have a MVC4 Web App and a Web-API service (hosted on two separate roles in azure)
Another role runs CustomSTS1.
The MVC Web App trusts the CustomSTS1
Now the customer logs into the site he is redirected to the STS login page.
Once logged in, he is redirected back to the MVC Web Site.
From this web site, the customer performs actions, which in turn invoke the web-API Service.
I have the SAML token in the web app, which I pass to the WebAPI service.
Now when I try to validate the SAML token at the Web API side, I get a
Message=ID1032: At least one 'audienceUri' must be specified in the SamlSecurityTokenRequirement when the AudienceUriMode is set to 'Always' or 'BearerKeyOnly'. Either add the valid URI values to the AudienceUris property of SamlSecurityTokenRequirement, or turn off checking by specifying an AudienceUriMode of 'Never' on the SamlSecurityTokenRequirement.
This is without the Web API service trusting the CustomSTS1
Once I setup the trust,
I am always given a HTTP 401: UNAUTHORIZED, whenever I try to make a HTTP Get request to the WEB API Service.
Now, My Question is, (I know that my current approach is definitely wrong)
How do I setup the Trust relationship with the CustomSTS1, such that the WebAPI service is able to do an ActAS on behalf of the user logged into the MVC site?
OR
Is this architecture wrong?
And is there another way to achieve this?
That approach is wrong conceptually. The MVC application should negotiate a new token for the Web API in the STS using ActAs. That's how it traditionally works for SOAP Services. However, Web APIs are moving away from SAML as it is a complex format that relies on different WS-* specs. OAuth 2.0 is becoming the standard in that area if you want to support SSO at that level.
Another approach is to establish an implicit trust between the MVC app and the Web API, so all the calls to the Web API from the MVC app are done through a more standard Http auth mechanism like Basic Auth using an specific set of credentials that only the MVC app knows. The info about the logged user in the MVC app is passed as additional information.
Regards,
Pablo.