Authenticate Microsoft Account user with ACS using REST - authentication

I would like to leverage ACS to authenticate Windows Account users (and eventually users from other identity providers in the future) on a website.
I have found a lot of resources regarding ACS, but most revolve around using WIF/using managed code in the UI layer in order to validate a user. I'd like to avoid that. Is it possible to retrieve a token from ACS by making a REST-based call to ACS using javascript/jQuery to retrieve a token for a Microsoft Account user?
One example that I saw that came close, is this link, however this uses a service identity instead of leveraging identity providers. http://code.msdn.microsoft.com/windowsazure/MVC4-Web-API-With-SWT-232d69da
Here's my end goal:
This website would have two layers, a UI layer (MVC 4) and a service layer (MVC WebAPI). Both of these layers will need to scale independently of each other in Azure.
I'd like to have the UI layer call ACS to determine if the current session is authenticated. If it is, I'd like ACS to return a token to the client. I'd like to store that token on the client as for use in step 3.
Once the user has logged in, I'd like to have the client make a REST based calls to the service layer passing the Microsoft Account/ACS user token along in the header of each request, completely bypassing the UI layer for this second service request. The service layer would authenticate the user with each request.
The client would handle the response codes (200, 401, ect) from the Service layer by either redirecting to the login page, or by displaying the results.
I am unsure about step 2. How would the client browser retrieve a token from ACS that it can pass along to the Service layer?
I essentially want to do what Vittorio describes here, but I want to use a MVC4 web app instead of a Windows 8 store app.

In step 2, your MVC4 Web App is a relying party and therefore relies on the claims in the token presented by the subject/user. So, rather than the UI call ACS, it's really just redirecting the user to ACS for authentication. Anyway, based on your requirements and description, I believe this is the solution you're looking for.
http://blogs.msdn.com/b/vbertocci/archive/2013/01/09/using-the-jwt-handler-for-implementing-poor-man-s-delegation-actas.aspx
Hope this helps.
-Rick

I wrote up this answer before reading Vittorio's blog post that Rick linked to. That seems to pretty much what you want. I'll answer anyway to give some more context on WIF and how this scenario works, but you should check out that post.
First, it's important to note that when using WIF in your MVC 4 application, no authentication or validation is happening in the UI/presentation layer. WIF works at the request layer, and does a lot of things you would have to do yourself if you chose to go the Javascript route (which I don't think is a valid route, though it could probably be done with a lot of work).
It goes like this: When a user hits a page that requires authentication, WIF redirects them to to ACS, where you are then sent to Google/Microsoft to login (the identity provider). After you've authenticated with your identity provider, ACS then posts the resulting access token and claims about the authenticated user back to your application (the return URL in ACS configuration). Finally, WIF handles validating the token that was sent by ACS (no small task), and creates a ClaimsPrincipal object in your application that can be used to identify the user.
It sounds like what you want is impersonation/delegation, where a user logs in and their credentials get carried through from frontend to backend. For this situation, I see no reason why you shouldn't just use WIF for user authentication in your MVC 4 app. The user authenticates and WIF handles/validates the token (though because you're calling a web API you should probably use the JWTTokenHandler for its lightweight-ness). You create an Action in your MVC project that sends a request to your Web API with the token in the Authorization header. Your Web API gets configured to read the Authorization header of incoming request, uses JWTTokenHandler to validate the token, then you're done. You can steal much of the code for the Web API portion from this code sample (particularly the code in Global.asax.cs): http://code.msdn.microsoft.com/AAL-Native-Application-to-fd648dcf

Related

Integration of frontend and resource server using okta authentication and client credentials API authentication

We have an application that has frontend UI(Which is a web application) which communicates with a resource server. Our frontend will be using some APIs from a resource server to get data.
I am planning to add frontend to Okta and provide access to okta registered users.
In the resource server, we have some APIs that we want to expose to our customers to integrate in their system(Programmatically). To use our APIs, we have to provide client credentials(client ID/secret) to them. Using clientId/Secret, they will get access_token and will use that in a subsequent request. We can display this clientId/Secret via frontend UI once the user logs in to it via Okta.
How should I authenticate requests to the resource server from the frontend? And how do I authenticate requests to resource server via customer using clientId/Secret? Should I use one or two different tokens for this purpose?
Does Okta provides per-user client Id/secret that user(customer) can use to get access_token and send it to access resource server and resource server validate token against Okta.
I just did something very similar. You can read about my experience here: How to pass/verify Open ID token between .net core web app and web api?
I don't know what application framework you are using (.net, node, etc), but if you're using .NET the steps are to (a) install the middleware in your web app, (b) install the middleware in your api app, and (c) make sure calls from your web app to the api app pass the id_token.
If you, in addition to that, need to secure it for external users - it should work the same way. The only difference is they will manually call the /authorize endpoint to get their token - but the middleware should take care of the token verification for you in both cases.
Note I did experience one odd thing which is that I needed to pass the id_token and not the access_token. It is also worth mentioning that the claims were interpreted differently in the app and the api (in that the name of the claims for say, userid, were different between them - the data was still the same).
You will have to use 2 different access tokens. There are 2 different flows going on here:
Web UI to API
Business partner system to API
Technically this means:
Authorization Code Flow (PKCE)
Client Credentials Flow
And in terms of tokens it means:
In the first case there is an end user represented in access tokens (the 'sub' claim)
In the second case there is only a Client Id claim in access tokens
I can advise on token validation techniques if needed - let me know.
To me though this feels like an architectural question - in particular around applying authorization after identifying the caller and versioning / upgrades.
Based on my experience I tend to prefer the following architecture these days, based on 2 levels of APIs: eg with these ones exposed to the internet:
User Experience API serves the UI
Partner API deals with B2B
And both entry point APIs call the same core services which are internal. Might be worth discussing with your stakeholders ..

Validate external token asp net core

I'm doing a mobile app in Xamarin Forms, which should be able to connect to an ASP.NET core web service (API). I also want the information on the web service to be secured by limiting it to Microsoft account signed-in users. The idea I had was to send the user's credentials and retrieve back the security token from the Microsoft graph within the mobile app. Afterwards, the user would send that same bearer token to the web service, which checks its validity, and grants the requested information only if the validation is successful.
I am new to web development, so first of all, I want to ask if I am using a good approach for my project (if not, what do you recommend?).
If it is, how should I set up the ConfigureServices function in my Startup class? When I include the [Authorize] tag in the controllers, the service crashes, telling me I should define an authentication scheme. I don't need authentication, only authorization (since authentication is done from the mobile app), Since these two are handled independently in asp.net core, I added a dummy jwt authentication scheme as a placeholder. However, when I send an http request with the security token from my mobile app, it gives me a 401 unauthorized error, telling me I'm sending an "invalid token" (this token works fine when connecting to the Microsoft graph).
I've searched in countless documentations, but all of them only consider scenarios in which the authentication is done within the web service, and not externally, like me.
Any help is appreciated

Managing ClaimsPrincipal.Current in Forms Authentication MVC app

We use the excellent Thinktecture IdentityServer v2 to manage our authentication. This works with an underlying SqlMembershipProvider architecture. I'd like to manage an ASP.NET MVC4 web application connection with the informations (claims) returned in the token by Identity Server. For now, I just set the authorization cookie with the username when the OAuth2Client.RequestResourceOwnerPasswordAsync() returns an AccessToken. I don't even validate it (which would set the ClaimsPrincipal.Current) because it's purpose is to be used on another web API I call later, so it's validated in this web API.
If I validate the token and set ClaimsPrincipal.Current.Identity to the the one I get, what is the mechanism to retreive it on every call ? Do I have to cache the token and valide it again on every request to get it ?
The purpose of all this would be to get my claims on the wep app side so I could apply authorization filters based on them.
Brock Allen from Thinktecture pointed me 2 great posts of his that answer all of my concerns !
http://brockallen.com/2013/01/26/replacing-forms-authentication-with-wifs-session-authentication-module-sam-to-enable-claims-aware-identity/
OR
http://brockallen.com/2013/10/24/a-primer-on-owin-cookie-authentication-middleware-for-the-asp-net-developer/

Securing ASP.Net Web API with API Key

I'm developing an ASP.Net MVC 4 Web API application where this application will be the source data for different Mobile/Web client apps. I need to authenticate a user so I can return the correct set of content for the user. I'm thinking about using an API Key that is sent to every request of my Web API application. The API Key identifies the user. I found this post that outlines a potential solution: From API Key to User with ASP.NET Web API
I need to support forms authentication as well as oAuth 2.0 for Facebook, Twitter, etc. All of these approaches yield a token I can use to send back and forth from the different clients to my Web API so I can identify the user. I understand Facebook access tokens expire. I'm a little confused on what's the best way to deal with Facebook interactions. Which of the following paths is the best way to go:
Rely on the different client apps to authenticate against Facebook (and other oAuth providers) to establish a Facebook access token that's then forwarded to my Web API application? This means all of the clients are responsible for making sure the Facebook access token is not expired. The Web API app assumes the access token is always valid. This seems dangerous to me. The different apps would authenticate the user then send user information to WebAPI app to register the user in order for the user to consume the data from my Web API app. This seems like a lot of duplication.
Make my Web API application solely responsible for interacting with Facebook (and other oAuth providers) on behalf of all the different client apps using my Web API. So this approach seems to suggest I need to build some sort of authenticating UI for my Web API app. I know ASP.Net MVC Web API can have views and front end stuff, but it always seems to me that you are mixing things together. It seems Web API apps should be singularly focused on returning data. Users from all of the different client apps will register with my Web Api app by either filling out a registration form, or using Facebook, Twitter, etc. Is it OK to mix UI views in with a pure REST Web API application? Then you have to start worrying about everything that goes with UIs on different devices, etc.
Is there another way I'm not seeing?
I really appreciate any guidance and links to examples you might have. Thanks for your time.
I would suggest you below approach:
1. Create an authentication API which will authenticate the user. If user is authenticated successfully, create a session (self implemented, may be a record in your db) for that user.
2. Next time user call your other APIs which returns content for that user. In this case it would be must for that user to provider the session id (which you have created in first step) to get the content. If sessionId provided by user does not exist at your end, it means the user is not authenticated. In this case you can return authentication error message to the user telling that he needs to get authenticated first. It is very flexible, scaleable solution in a way that you can store many information regarding that user session. Also once authenticated, user does not need to get authenticated every time he calls your other APIs to get content. It would save you as well from authenticating the user every time.

Claims aware security. Do I get it right?

I'm trying to investigate possibility of using claims aware security in the system I'm developing. The more I read about all this stuff the more confused i get.
So i decided to describe what I know already and I would ask that You correct my statements. I got lost with all those protocols and technologies used.
Below is a simple diagram of my system. There are two services - a REST service implemented using WCF and an ASP MVC web application.
I know I need to get an STS which will be a trusted identity issuer for both of my services. I'll be using roles to differentiate certain levels of access.
The STS functionality might be accomplished by using ADFS (or is there anything more needed in addition to it) or WSO2 Identity Server.
By saying STS I mean a service which will get credentials from a client wanting to authenticate and will return a set of claims (which will beside other information contain the role assigned to the user). This set of claims will be in the form of a token.
On the diagram I marked different client types with different colors. No I'll try to describe what protocols/formats i think will be used. I am pretty confused on what is a format and what is a protocol. But let me try:
Red scenario: rich WCF client authenticates agains REST service
Request to STS will be sent using WS-trust (is there any other possibility in ADFS or WSO2?). The credentials might be in one of several forms such as X.509 certificate, password digest, kerberos, windows authentication, SAML token (this is used in federation scenarios, right?), and few other.
The answer to the client will be in a form of SWT token sent over OAuth protocol since this is the way we do it when trying to authenticate against REST services.
Does ADFS support SWT and OAuth? I couldn't find the information.
The client then send the token received from STS to the REST service. Once again this is SWT token on OAuth.
I guess as for the client code all can be easily implemented using Windows Identity Framework.
Green scenario: rich android client authenticates against REST service
All protocols/formats are the same as in previous scenario. Is there any framework which can let me easily implement this?
Blue scenario: user of web browser authenticates against ASP MVC web application
User goes to the web app's main page. The webapp detects that he isn't authenticated yet so redirects him to the sign on page on STS (the sign on page is on STS, right?).
and 3. STS authenticates the user and sends HTTP response containing SAML token and redirection to webapp. So here is HTTP used, not WS-Trusts.
Another question. In this web browser scenario there will be a cookie written on a client's machine. So whenever client will try to authenticate once again, he'll just send the cookie to sts to obtain the token. There will be no need to send the credentials. STS will issue a token basing on the cookie without any real authentication logic involved. Is that statement correct?
ADFS / WIF out the box only supports SAML tokens - no OAuth support.
ADFS / WCF uses WS-Trust.
The sign-on page is part of ADFS.
The answer is "Yes" to your last question but (at some point) it will expire and the user will have to authenticate again.
Update:
Have a look at Claims Based Identity & Access Control Guide