We are trying to take user login thru an MVC app (not redirect), but have primary authentication done through a Web API 2.0 endpoint, but also be able to authenticate user access to pages from that point on. Naturally we would track the token needed to authenticate future API calls.
However, there is no established User.Identity in the MVC app since we are doing this externally, and we need this User.Identity to enforce authentication for the MVC pages themselves (on a level before it reaches the controller).
So how can I adopt or impersonate the user?
I would've thought the general area of external auth would be it, but when I look at the diagrams showing how it would work, both seem to involve the user's machine directly interacting with the authenticating server (http://www.asp.net/web-api/overview/security/external-authentication-services). We want the API to be inaccessible by the user's machine, except through the web app, so redirects of requests TO the API are not acceptable.
Related
I have been tasked with integrating single-sign-on for an existing application, so I've been working on a couple of demos. The first one was the standard demo for Spring Security and I got that working. Now I'm trying to do a proof-of-concept demo where I created a toy version of the application in question with only two screens: one for login, and one to display some information about the user that logged in. I want to integrate SSO with this application so that the user has two ways to be authenticated: either by entering credentials directly in the login screen or by a SSO SAML request...
So I copied over SAML libraries and configurations from the standard SSO demo into my proof-of-concept application, and I seem to have SSO working, albeit a bit too well, in that I'm no longer able to get to my login screen, i.e., I still want that to be the default behaviour for someone entering the base URL for the application. How do I have to configure my application to achieve this?
The way I solved the problem was by changing the Spring Security configuration so that instead of using the generic /** to require SSO authentication for most pages of the application, it nows only requires such authentication for a single HTML page, sso.htm. This "page" is really translated by the application as a request to a controller that handles the application-specific processing for an SSO request. The initial page for the application, redirect.jsp, now contains some logic to pick which page a user should be redirected to, based on whether he or she got to that page directly (i.e., by typing in the default URL for the application) or via a SAML message from a trusted identity provider.
Note: For this to work, the initial page cannot be designated in the Spring Security configuration as either a secured or unsecured page. If it were secured, then this page could only be accessed after an SSO authentication, so a user would be thwarted from doing a non-SSO login. If unsecured, then the security context would not be accessible from that page, so the page logic would be unable to determine if the user in question has SAML credentials and an SSO authentication request for the application could never be fulfilled.
Once the user has been authenticated, either by credentials entered in the login screen or by an SSO request, from that point on, the application's continuing authentication of that user to view its pages is the same, i.e., no further SSO authentication is done. But when the user logs off from the application (or is logged off due to a session timeout), a check is made then to see if SSO authentication was done for this user. If so, then in addition to being logged out from the application, a local SSO logout is also done for the user, i.e., the SSO authentication session for the application is terminated, but the user remains logged in with his or her identity provider. So such a user could log back into the application in question, either directly via the application's login screen or by having the identity provider issue a new SAML message.
Hope this helps someone else...
I work on an application where I have a separate MVC layer and Web API Layer, both have the same authentication mechanism, I have chosen the individual accounts authentication option while adding the projects. The web api service layer will be directly accessed by some other mobile clients also.
But when the user logs in through MVC he should be able to access Web Api seamlessly, but I don’t want to really pass the username and password from MVC to the Web Api layer, I am told it is a bad practice. but i need to authenticate and authorize my user, so the only option i have thought of is to have a default account at Web API level to issue tokens, and this will be called from MVC post the authentication and a token will be returned which is written to a cookie in the client. Now the Ajax calls from the UI can use this bearer token and get the job done.
The only glitch I have here is that, because I am using a default account I need user details again for authorization at service level, though I am doing authorization at my UI level, the user can spoof the system. I was lost here and came up with a solution like, when the user logs in to MVC will send across user details also along with the call to get the WebAPI token and issue another token to the user so that the user uses both of the tokens to make a call to web api from MVC.
I am not sure if this works or if it is even the best way. I just wanted to check, how I should go from here. Any help on this will be really great.
This is a really good example of integration - I know they use Angular as the client but you can learn from this:
http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/
Check this section to see how they decouple the API from the front end (Part of the same article).
http://bitoftech.net/2014/09/24/decouple-owin-authorization-server-resource-server-oauth-2-0-web-api/
I have a RESTful API written in ASP.Net that implements OAuth 2 for authentication, and it's currently accessed through a web application. I've also got a legacy desktop client that accesses the same resources directly (not through the RESTful API and without OAuth, but using the same login credentials and hitting the same database). The requirement I'm trying to meet right now is to allow a user to click a link in the desktop application in order to open the web app to a specific screen, and when they do, to have the web app authenticate automatically so that they don't have to manually log into it (since they've already logged into the desktop app).
I'm trying to work out how I can handle this within the constraints of the framework. I'm not too familiar with OAuth 2 in general, but from what I understand I shouldn't share tokens between clients and there are no flows specifically for this kind of hand-off (unless I'm missing something). Worst case scenario, I could generate a temporary token outside of OAuth that's used by the web client to authenticate rather than a username and password, but I'm hoping to avoid stepping outside of what's already in the framework to do what I need to do.
So the question is this: is there some decent way built into the OAuth 2.0 framework to handle this sort of "handshake" between two applications, or should I just build my own method of dealing with it?
Using temporary one-time tokens is actually part of OAuth spec (authorization_code grant type). In this case this short-lived code can be exchanged for access_token (and refresh_token). You will have to implemenent generating and validating of this authorization_code.
If you are using OWIN OAuth middleware:
You can generate the code at separate API endpoint accessed by your desktop client app.
After receiving token, pass it to your browser and direct it to auth endpoint with grant_type=authorization_code over secure connection. Example: call Process.Start("https://example.com/ExternalLogin/authorization_code_goes_here"). At the webpage redirect user to your OAuth Token endpoint with grant_type=authorization_code.
AuthenticationTokenProvider.Receive will be called, in which you will validate your token. (Example code here).
After successful validation OAuthAuthorizationServerProvider.GrantAuthorizationCode will be called, in which you will process the authenticated user in the same way you process it with grant_type=password.
Remember that your token validation logic should ensure that your tokens are short-lived, usable only once and transmitted over secure connection.
This is sometimes called "single sign-on" if you want to research this topic further.
I have three asp.net applications. Only one of them has a forms authentication login. I redirect anonymous users to that one login page for all three applications to login. Once they log in, they automatically redirected back to the application and page they were attempting to access.
I enabled this functionality by setting the same MachineKey in all three applications.
Is there a way to do this for ADFS 3.0 WIF authentication as well? It doesn't seem to work the same in my testing. When I log into the application that is wired up to ADFS, I still can't access the other two.
WIF and ADFS don't work the same way as traditional forms authentication. These technologies rely on issuing access tokens, and require that dependent applications (also known as Relying Parties, or RPs) configure a trust relationship with the token provider (AKA Identity Provider, or IP). You can't share the cookie with MachineKey between apps that have not directly authenticated with an IP, and to be quite honest you don't want to.
The typical web scenario (also known as Passive Federation) is to have a separate application that functions as a Security Token Service (STS). This application houses the Login.aspx page and is protected with Forms or Windows Authentication like you would find in a classic ASP.NET scenario. When you attempt to access a web application that requires authentication, it needs to be set up to redirect you to the STS website, rather than handling it by itself. Once you log into the central STS, it will issue you a token that you then provide to applications to gain access. If you use WIF properly, this is all handled behind the scenes and is just a matter of configuration.
Each of your three web applications should be configured with a trust relationship to your IP. You said that you have a web application wired up to ADFS already, if that's via the proper trust relationship, then you should simply have to replicate that set up to your other 2 applications.
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.