How can I share Azure Active Directory authentication between server side and client script? - authentication

I currently have an MVC app that's using the Microsoft.Owin.Security.WSFederation package for authentication with Azure's Active Directory. This lets me use the Authorize attribute on my controllers to redirect users to the Microsoft login site.
I now have the requirement to add access to a WebAPI project that will be hosted on a different domain but will use the same AD store.
I've managed to pull together something using the ADAL JS library provided by Azure but this gives the following process:
user visits site and is redirected to Azure login
user logs in and is returned to site
JS code checks for login and redirects to Azure
user is already authenticated so redirects back to site with token
JS picks up token, stores it, and redirects to the original page
So it works, but involves 4 redirects, which seems like a huge overhead.
I thought that there might be some way of pulling a bearer token out of the authorisation credentials returned when the WSFederation succeeds but I can't see anything like that in the data. And, even if I could, I don't know how I'd be able to then refresh the token from the client script. So I strongly suspect I'm doing something fundamentally wrong.
What would be the best process for sharing authentication between the two sites?

Related

Vue.js + Django + Login with Microsoft

I have a SaaS application using Vue.JS as frontend and Django Rest Framework as backend. I use JWT tokens for authorizing between frontend and backend.
Now I want to add support for our customers to be able to sign in with their Microsoft accounts. So if the signed in user matches a user in our database, it is logged in to our application.
I've set up Azure B2C and can successfully log in and acquire a token in the Vue.JS application using msal library.
Then I send the token to backend server for verification. I use azure_ad_verify_token to verify the token, but I get an InvalidAuthorizationToken exception.
It seems to be working when the user is added to my organization's AD directory. But I would like to verify the token for any Microsoft user, then match it to users in our database. It would be too much work to manually add our customer's users to our AD directory. If it would be possible to add another organization/domain I guess that would be ok.
There's a lot of documentation regarding this but I always end up in examples for separate applications. Just to clearify flow I try to achieve.
The user clicks on login with microsoft
The user is redirected to Microsofts login page, approves my application for their organization
On requests sent to our backend, the token should be verified against Azure Active Directory using authorization class.
If the user's email exists in our database, the request is successful

Getting access token from Microsoft AD Application without redirection

Requirments
I have created a Web API that requires access token from Microsoft Active Directory Application and then uses the access token in a subsequent request to Web API. I am consuming these Web APIs in my PowerApp components. However, I am unable to get the access token internally from Javascript without redirecting the user to the login page. As per my requirements, I have to get the access token and then access my Web APIs, without redirecting the user to login.
Implementation
I am making a POST call to "https://login.microsoftonline.com/{tanent_id}/oauth2/token" from JS and trying to get the access token by using client secret.
Issue
I am getting the CORS issue whenever trying to reach the login API. I can get the access token from Postman and Internet Explorer but not to the rest of the browsers (i.e. Chrome, Firefox, Edge).
Can someone suggest me the way to prevent the CORS issue and proceed with my Web APIs calls with the access token. I have already learned the Implicit approach and it did not work since we need to redirect to URL in this approach too.
Since Implicit Grant Flow is not your option, and you do need an app-only token, I am afraid you must do the request from a back-end application. Then you can get the access token from the back-end application.

Common login web to redirect to separate webs

I have 3 separate net core web apps on the same IIS web server. All of them are equals at 90% but every one has its own database, its own users and its own subdomain.
I would like to have a unique web app to login into the corresponding final web app depending on the user logged, basicly because I need all the users to access from a specific URL login.my-platform.com By now every user access through its web app with a login page on its subdomain.
USER FINAL WEB APP
==================================
111 platfA.my-platform.com
222 platfA.my-platform.com
333 platfB.my-platform.com
444 platfB.my-platform.com
555 platfC.my-platform.com
Moreover, from a final web app, a user could create more users to that final web app, so the user will be accesible from the login web app.
I think an inappropriate solution would be to try to loggin to the 3 different databases changing the connectionString value and set a short connection timeout, but I want to avoid it. I think there must be a better solution and I just need a little bit of lighting. Thanks
There's two approaches:
Shared cookies
Distributed auth
The first method is available only because all of these sites share the same primary domain, i.e. my-platform.com. If that's not the case or it changes in the future, this won't work. You'll need to do two things: every site will need to be configured to use the same auth cookie name and domain (the wildcard .my-platform.com). Then, you'll need to set up a data protection provider on each that pulls from the same source. See this article for more info.
The second method, is more complicated, but also more robust. You'll need to utilize something like IdentityServer4 or a third-party service like Auth0. The former requires more code and configuration, but is free; the latter is virtually drop-in but not free and can become quite expensive, in fact, depending on your usage. In either case, your applications will connect to this distributed auth service for both authentication and authorization. For normal user login, you'd like follow an OpenID Connect workflow, where the user will be redirected to the distributed auth website to authenticate and then will be redirected back to the originating website with a token. The originating website, then, can use this token to request the user claim, and then set a cookie in the normal way.

Authenticating AD user automatically and manually - WebAPI 2 server and SPA client

I'm developing an Enterprise/Internet Application with WebAPI 2 RESTful server and SPA web client (Angular2) —So I have two separated projects created using ASP.NET 4.6 Empty template and both use OWIN and are IIS hosted.
The requirement for Authentication is:
Active Directory user which is logged in to the workstation will authenticated automatically once she opens any page from app in the browser if user id/name found in the database, with no need to enter her user/pass. Let name this as auto-login. Else if it's not found in the DB it will redirected to the login page.
Also there should be a logout option which redirects user to the login page after logging she out.
In the login page any AD user can enter her/his AD user&pass and after successful check against database (existed) and AD (valid credential) she/he will logged in to the system (Obviously it may be different than user currently is logged in to the workstation)
In addition to the web client it will have other clients such mobile apps which will connect and be served by the WebAPI back-end. Users will login there using their AD user & pass too. Let name it manual-login.
According to the REST architecture and having both AD enterprise and internet/mobile users together, the authentication should be token based —this is what I found till now but I'm not sure.
I read about OWIN Authentication architecture and Windows Authentication and I checked MixedAuth, Now I think it is the nearest solution for this requirement as it lets app-defined users to authenticate side by side of windows/AD users. But even after dig into it and its SPA sample I didn't found my way yet and confused.
Anyone can help?
What should I actually do on the WebApi server and SPA Client to accomplish those authentication requirements?
Which middlewares should I add and how should config/manipulate them?
UseCookieAuthentication ?
UseExternalSignInCookie ?
UseOAuthBearerTokens ?
Can I rely just on Bearer tokens (using OAuthBearerTokens MW) and get same token for authenticated windows users to unify authentication model based on bearer tokens? If so, how?
How and where should I put my code for checking that AD user exists in the DB and if not so reject the authentication?
Thanks a lot.

asp.net 5 and IdentityServer4

I am working on a prototype for a site re-architecture using ASP.NET 5 and I am debating using IdentityServer4 for my Authentication and Authorization. I have reviewed a lot of samples and articles about setting up IdentityServer3 and 4 and I am trying to wrap my head around if it can handle my client’s requirements in a proper way. Here are my requirements.
I have 3 sites that need authorization. Site 1 (abc.com) will require windows authentication and will be a combination of mvc and webapi calls using roles (or roles converted to claims) for authorization. Site 2 (def.com) is a trusted site that wants a login widget with a username/password/rememberme text box on their site that when submitted will authenticate the user and redirect them to site 3 (xyz.com). Site 3 will also have its own login page and will be a combination of mvc and webapi calls using claims. Site 2 and 3 will not be using windows authentication and the client does not want them redirecting to the identity server login screen, but rather having their own login screen and calling the identity server from code with the credentials to login.
Here are my questions regarding this scenario and IdentityServer4.
Can Idsvr4 handle one client using windows authentication and
another using username/password authentication?
If so, is there a
reason to have windows auth in idsvr4 or should it just use standard
windows auth within the webapp?
Can idsvr4 be setup to have the client collect the username/password/rememberme values and pass them through code to
get the proper jwt tokens for both mvc and webapi?
If so, can it
log them into both the mvc and webapi applications on another site?
If so, is this circumventing the real purpose of identityserver4
and therefor is a bad idea?
If it can handle this scenario and is a good idea, how would I setup the client, scopes and code to handle the login through code and redirect?
Examples are great and very welcome, but I am not even sure what verbiage to use to search for this scenario so even pointing me in the right direction would be of great help.
Not sure if this question is still active. But yes, i believe you can do all that.
1) You can setup which ldp is available for each client by setting IdentityProviderRestrictions on the client (docs)
1.1) - Not sure what you mean, i believe one of the points of having idsrv is to sentralize you authentication, and it makes it easier for future websites to integrate with the same service.
2) When logging in using a client (application), you also specify which apiResource the client has access to - and the application needs to add this to the requested scopes when signing in. So if your client is the mvc application, you just add the ApiResource in the AllowedScopes - and set the request_type to id_token code - this would then give the user a access_token that is passed with each request to the backend api. (docs)
2.1) - This would basically log the user in on both sites - using an access token that says that the user is authorized to use the backend api.
2.2) - In my opinion this flow is one of the things that makes idsrv great - and they even mention this as a great feature of idsrv themself. You just need 1 trip to the authserver to gain access to all systems.
as for pt. 3 - Take an extra look at the docs, try to setup a blank project following the quickstarts.
For logging in from your own login page, you need to use the grant type Resource Owner password - Altough they dont recommend doing this for security issues (transmitting passwords over the wire) - it is supported.