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?
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.
After 2 days of research ,now i am at assumption that ADFS can be used as Identity Provider which uses Active Directory as its Repository (this means we can store Username,password... required to identify user) .My confusions are
When a user opens a login Page in SP ,and if there is trust
relationship between SP and ADFS(IP) ,does the IP takes the windows
logged in UserId to check user from active directory ?
If the authentication is successful then does IP sends
UserInformation(as a SAML responce) to SP ,so that i can create
session for logged in user ?
what should i do ,if user logs out from SP ,should i also have to
clear session in IP(now ADFS)
if my assumption are right ,how to implement ADFS as Identity Provider (IP) and consume its service in Asp.net Application (Service Provider) ?
When the SP notices that the user is not signed in it sends the user to the IDP. This is where the login page is presented. ADFS can be configured to authenticate the user based on the signed in windows user.
Yes ADFS can be configured to return user information in the SAML response. This is defined as claims in ADFS
When the user is logged out in the SP, the SP should send a SAML LogoutRequest to the IDP to remove the session on the IDP.
Here is a library I have seen others use for .net
Another option is to use a product such as Shibboleth in front of you application
Your question is: "How to implement ADFS as Identity Provider (IP) and consume its service in Asp.net Application (Service Provider)"
Then you have tagged it with SAML?
Why do you want to use SAML? (And here I am talking about SAML the protocol NOT SAML the token).
Just use WS-Federation and WIF which is OOTB support. WS-Fed also uses SAML tokens.
If you want to use SAML, refer SAML : SAML connectivity / toolkit and SAML : ASP.NET MVC application talking to SAML IDP .
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.
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
I have an ASP.NET application which uses login cookies already. I need to provide a link in my application upon clicking which the user should be able to access their info in SalesForce.com using SSO. I'm planning to implement this link as an ASP page that constructs a SAML assertion with the corresponding username in SalesForce.com, posts the SAML assertion to SalesForce.com SAML Endpoint URL, receives the SAML response from SalesForce.com and redirects the user to the session URL contained in the response.
Has anyone tried this approach instead of using a dedicated SSO server (such as OpenAM) ? Are there any issues in this approach ?
You won't be able to do that, because it would require you to implement most of SAML IdP (identity provider) piece on your own.
SAML is a complex standard involving multiple interactions between IdP and SP (service provider), it is so much more than just sending an assertion.
To enable SAML you'll need to install IdP (like OpenAM), connect it to your user database and to convert your application to SP.
Wikipedia has more detail on SAML iteractions.