I have used Owin in the past to create a token endpoint in my Mvc Web Api projects to provide oauth 2.0 tokens with "Resource Owner Password Credentials" grant type where access token provider would check a database user table to verify the validity of the credentials supplied by the mobile client (multiplatform App developed with Visual studio tool for Cordova).
In this project, the Web Api will be consumed by a multiplatform Mobile app used by Active Directory Windows domain accounts
I would like to use Owin Oauth 2.0 to grant an Access Token to these users but I don't know how to check the validity of these credentials.
What I was thinking is to put the /token endpoint behind "basic authentication" and in the code of the Access Token Provider get the user from the Identity that, in case of authenticated used, should be automatically created by the Asp.net pipeline.
Is it something that could work?
Do you know any better idea to use Oauth 2.0 for AD Windows Accounts?
Note:
I'm also investigating if Active Directory is able to provide an Oauth 2.0 endpoint by itself.
Here is a pretty good walkthrough of how to use Active Directory Federation Services to obtain an OAuth2 token.
https://technet.microsoft.com/en-us/library/dn633593.aspx.
You'll have to follow all the links at the bottom to get the entire walkthrough.
Note that it refers to using Windows Azure AD Authentication Library for .NET. But according to that documentation, that library is used for both Azure Active Directory and on premises Active Directory.
As for the workflow, once authenticated you'll be able to obtain and present a bearer token to your WebAPI. Your WebAPI then "validates the signature of the token to ensure it was issued by AD FS, checks to see if the token is still valid and hasn’t expired and may possibly also validate other claims in the token. At this point, the client is either authorized and the information they requested is sent in the response or they are unauthorized and no data will be sent." - https://technet.microsoft.com/en-us/library/dn633593.aspx
You could use ADFS 3.0 on top of AD which would provide you with OAuth 2.0 Authorization Server functionality: http://blog.scottlogic.com/2015/03/09/OAUTH2-Authentication-with-ADFS-3.0.html
Putting the token endpoint behind "basic authentication" does not help you because you'd be authenticating the client on the token endpoint, not the user. You could put the authorization endpoint behind "basic authentication" though.
Related
We want to build one spring MVC based application which will support below use case:
User access the application URL to login into application.
Once the valid credentials are entered to login into application, the user can access any of the service provider application for performing SSO.
On the access of any service provider application the SAML response should be generated and post to the Service provider ACS(Assertion consumer service) URL.
Also in addition to IDP initiated SSO, it should also support SP initiated SSO where the authentication request will we posted to the application login page, after valid credentials are entered by user, the application should redirect to service provider(which have posted the authentication request).
The application should have its own login page and authentication mechanism, it should not redirect to any other identity provider for authentication.
Should we use normal Spring MVC based application which will generated the SAML response using open SAML library, or any other SAML builder can be used for satisfying the above use case.
This basically means
- your app bundles a SAMLv2 compliant IdP (please don't try to build one yourself based on some SAML lib)
- your app calls an API of the IdP for authentication and issues a session token the IdP will recognize later on (otherwise authentication will always happen again when another application (acting as SAMLv2 SP) wants to perform SSO
Issue with the latter: The "token" will most likely be a cookie and then the restrictions of the cookie spec apply. This means you can only use host-based cookies (which security mandates) if your app and the IdP are deployed behind the same 'FQDN' (e.g. by using an HTTP reverse-proxy)
Another issue: How does your app know when the show the 'login screen' if the user actually has a valid session with the IdP because SSO was started at a different SP?
SAML way: You would first have to do a 'passive AuthnRequest' to check this.
Conclusion: Your use case can be achieved, but the effort seems quite high. I'm not aware that there is some lib/framework, which would offers this at the moment OOTB.
I have a design requirement for an ASP.NET MVC 4 (.NET 4.6.1) app hosted on the company server (Not Azure) to do the following:
Check is user is authenticated via Windows Authentication
a)Yes - designate user as "authenticated"
b)No - use OpenIdConnect (OWIN) to authentication using Azure Active Directory.
Once authenticated use the standard [Authorize] attributes on controller methods etc. I have implemented Windows and Azure AD authentication alone is individual MVC apps but never together.
I have found several sources describing how to mix Windows and Forms authentication, but none for this combination.
Does anyone have insights on how this might be achieved?
I had a similar requirement a year ago and my approach was :
The users are redirected to input their AD credentials (https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-how-to-configure-active-directory-authentication/)
Once they are sucessfully logged in on the AD you will get a token.
Then I call the Azure AD API on their behalf using the token I just got. I woulds just call the /me endpoint that will return me the user personal details.
With the above response I just need to check if the email address matches the email address that was initially requested.
If it matches it means the user was successfully validated against the AD.
Then you can proceed and issue that user a token or cookie to access your application.
I'm following the guide and example provided by Microsoft here and I'm able to get the demo working, with the authentication happening in a console app, then making a request to a Web API with the correct token.
I'm looking to use this but the code in the console app would need to move to a Web App. Essentially: external server tries to access secure Web API, providing Azure AD username/password in the Authentication header of a HTTPS request. I pick up these credentials in the first insecure Web API, and attempt to authenticate the credentials against AD, obtaining the token. From here, I would then call the [Authorize]-protected Web API by making a request with the AD token.
At this point I'm using the same code from the example linked above, simply moving the code in the Console app up into the first insecure Web API controller, but I'm having no luck. I read on CloudIdentity that "You can only use those flows from a native client. A confidential client, such as a web site, cannot use direct user credentials.". Is this true? If so, is there another way to achieve my aim? I need to use the credentials as it may be likely that more services would use the API in the future, so each of these would need their own credentials to use that could be managed within Azure.
EDIT: In reading more around this, should I actually be aiming to use Client authentication, creating an "Application" within the Azure AD, and providing the client ID to each external service looking to call the API, to then authenticate with that, rather than credentials?
Yes, your edit is correct. The Resource Owner Password Credentials grant is meant to authenticate users, not applications. Typical use would be from an application that prompts you for username and password and then retrieves a token from Azure AD.
You can use the Client Credentials grant to get a token from Azure AD from a confidential client to call an API without user context. This flow requires that you register the application in Azure AD and generate a key (which will be used as the client secret). You can then use the ADAL library to ge a token from AAD as shown here.
I am working on a web application which should authenticate users via ADFS. WS-FED Passive was chosen as the simplest and fastest to implement.
The setup went smooth and the application seemed working: a user is first redirected to the the Identity Provider service, enters username/password and in case of success a SAML token is POSTed back to the web app.
Here where I get confused: a SAML token can be validated via the Signature and X509Certificate data which are contained in it.
However, what is the proper mechanism to verify that the token was POSTed by the Identity Provider service, not by a third-party which also posesses the certificate?
I have created an ASP.NET application and an Azure-AD domain. Currently, I have the ASP.NET auth set up to hit the wsfed endpoint in Azure-AD. Everything works fine, but the problem is that this issues a SAML token and I need a JWT. From what I have read after much internet searching, I need to authenticate to the OAuth 2.0 endpoint of my Azure-AD domain. The trouble with this is that with everything configured the way it is, I always get back a 400 from this endpoint, likely because my config file is all set up for fed auth. My question is how do I configure my ASP.NET application so that it can talk to the OAuth 2.0 endpoint of my Azure-AD domain?
I need to use passive authentication.
Azure AD supports the OAuth2.0 flow that you can execute once the user has signed in using passive authentication, to receive access tokens to make delegated calls to WebAPIs on behalf of the user. You can use the Active Directory Authentication Library (ADAL SDK) to execute the OAuth flow. This sample application does exactly that: http://code.msdn.microsoft.com/AAL-Server-to-Server-9aafccc1
However, for your scenario, we recommend the OpenId Connect flow now, instead of SAML SSO + OAuth. With Azure AD OpenIDConnect flow, the Web Application receives an SSO token (JWT id_token) using which it signs-in the user, and also receives an auth code (OAuth auth code) that it can redeem for an Access Token (JWT access token) to access WebAPIs on behalf of the user. Azure AD provides an OWIN component that does this. This sample application should see you through: https://github.com/AzureADSamples/WebApp-WebAPI-OpenIDConnect-DotNet
Finally, refer to this help topic to find all authentications flows supported and recommended by Azure AD for your Web Apps/APIs and Rich-Client/Mobile Apps: http://msdn.microsoft.com/en-us/library/azure/dn499820.aspx
Hope this helps