I have a web application that is capable of being a SAML 2.0 IdP as well as a SP, and have successfully implemented SSO between my platform and ADFS, but only when ADFS is the IdP.
This is my first foray into integrating with my platform, using ADFS as a SP and I'm having problems understanding the SSO flow.
In my situation, I have three players: WebApp (IdP), ADFS (SP), RelyingParty (S). The trusts are set up in ADFS, and the user experience is supposed to be a successful login to the RelyingParty having logged in to the WebApp
Setting up a new Claims Provider Trust in ADFS with my web app appear to work perfectly. I can go to my app's IdP-initiated URL which sends an unsolicited SAML message to ADFS's ACS URL. When I do this, I get redirected to /idpinitiatedsignon with the message "You are signed in" and a drop-down of the relying parties I've already set up.
If I click on the login button for the RP, ADFS generates a new AuthNRequest to my web app before eventually getting to the Relying Party.
So, seeing this behaviour, I have two questions:
I would have thought that the initial sign in to ADFS via my IdP-initiated login would have got me though to my RP without the need for going back to the IdP for another sign-in. have I misunderstood, or have I just misconfigured ADFS?
What mechanism is ADFS determining that my IdP is to be used? If I go to the ADFS /adfs/ls/idpinitiatedsignon.aspx page in a browser, I've not involved my IdP at all, and selecting my RP does use my IdP to authorize the user but I've no idea how this is determined since there's no link between the Trust Claims Provider and the Relying Party in ADFS configuration.
What happens if you use loginToRp:
https://your-adfs-server/adfs/ls/IdpInitiated.aspx?loginToRp=your:relying:party:id
You have chosen to use IDP Initiated to ADFS. So ADFS handles the authentication.
If you want to involve your IDP, you need to use SP-Initiated flow from the RelyingParty (S).
Then ADFS will show you the Home Realm Discovery screen and you can pick your IDP.
Related
Microsof ADFS supports below federation protocols:
SAML 2.0
WS-Federation
OpenID Connect
Would like to know is it possible to achieve single sign on (SSO) and single logout across different protocols? E.g. user X after he/she successfully login to website A which is protected under SAML 2.0, then the user can access website B which is protected under OpenID Connect without re-login? Both website A and website B point to the same IdP.
There are typically the parties involved. Of these, website B is the modern architecture and can support many forms of authentication:
Website A redirects to SAML Identity Provider (IDP) directly
Website B redirects to Authorization Server (AS) which redirects to the SAML IDP
Single Sign On is represented by a third party session cookie issued for the SAML IDP's domain name. Both apps would redirect to the SAML IDP but only the first would result in a login prompt. Website B may need to send the acr_values OpenID Connect parameter during its redirect, to avoid the user being presented with an authentication selection screen. It should work fine, but test for your providers. The SSO cookie is maintained in current browsers on the second redirect, due to the user gesture of a top level redirect.
Single Sign Out has always been a set of draft standards that work imperfectly in all of the above protocols. Even if the technology works, there would be risks such as also signing the user out of App C, which you do not own. Also, recent browser restrictions on third party cookies mean some techniques may drop the SSO cookie and no longer work. Most stakeholders, including end users and security reviewers, do not expect you to have a perfect Single Logout solution.
I am implementing front-channel SAML 2.0 SSO golang Service Provider, with Okta as my Identity Provider (this is just a POC and should eventually work with any IdP).
Implementing the sign on process was straightforward with saml2 package. I've created the login endpoint that redirects to the SAML application login URL at the intended IdP, as well as the POST callback endpoint which is properly receiving the SAML assertion and is able to validate it. After that a session with a random cookie is created with the same TTL as the Identity Provider session TTL. So far everything works well (I haven't implemented Single Sign-Out yet, but I'm planning to).
However, when some time passes and the session expires, I'd like to renew it only if the user is still logged in with the Idp and hasn't been removed from the SAML Application. I would like to avoid redirecting the user to perform SSO again with IdP, because it would mean that if they are still logged in, they would be redirected back to the home page of my application. I wasn't able to find great sources on my options to go about it online.
Questions:
1.1 One solution that comes to mind is storing the requested URL in the RelayState parameter, whenever the session has expired, then redirect the user to the IdP SSO URL. When the redirect returns to the SAML callback POST endpoint, check the RelayState parameter and if set, redirect back to that (original) URL. That means that for users that use the system continuously, I would have to request Assertions very often. Does that make sense?
1.2 A second solution that comes to mind is to implement a back-channel of communicating directly from my SP to the IdP. That would allow me to verify a user is still logged in 'behind the users back'. If that's a sound idea:
a. Do I need to have dedicated code for each IdP?
b. Do I need to load an API key to the IdP which would allow secure communication?
c. Do I need to upload a public certificate to the IdP that would be able to verify that my SP signed the requests?
Will using the Assertion to get an OAuth 2.0 Access Token help me in achieving this?
I've chosen SAML 2.0 for now, since the environment is an enterprise oriented one and I thought it fits well with it based on what I read. Would using OpenID Connect instead help achieve my goals easier and fit well with enterprise oriented products?
I am a SP developing SAML 2.0 capability for SSO.
The SSO will ALWAYS be initiated from the IdP (Users will get to my site from their Enterprise Portal, where they are already signed in).
So, what I am trying to understand is whether I should just offer unsolicited (IdP initiated) SSO, or is it still best practice to develop solicited (SP initiated) SSO. If the latter, then why do I need the added complexity?
When, as you suggest, users will always be initiated from the IDP - and in fact every IDP that the SP is connected to - then there's no need to add SP initiated SSO support to your SP.
Of course one may argue that having support for SP initiated SSO is more generic and a superset of IDP initiated SSO because you would be able to trigger SSO from outside the IDP portal as well as include SP initiated SSO links in your Enterprise Portal. But in your case the former would never be required so you may stick with IDP initiated SSO only, assuming that all connected IDPs support that.
SP-initiated SSO is best practise in general, and OWASP states that "Unsolicited Response is inherently less secure by design due to the lack of CSRF protection."
I have a scenario where I have four to five web based application, which needs to have a common centralized authentication system, in this case how feasible is the SAML based approach i.e each time user want to access any of these web application the user is redirected to SAML server which in return redirects to the IDP, or is their some better solution for such architecture as I am new to the this domain
What you describe is exactly what SAML is designed to solve.
The user is normally only redirected to the SAML Identity Provider (Idp) on the first access to an application (a service provider (SP)). When the user is successfully authenticated by the Idp, the SP sets a cookie in the user's browser to handle authentication of subsequent requests.
I'm in the midst of finding some means (preferably through Java code) that will enable me to get the SAML assertion from the IDP (i.e. ForgeRock's OpenAM) for a Service Provider (SP) via SSO Login.
The SP have already been configured to interact with the IDP (e.g. vCloud Director --> OpenAM and vice versa) through a Web Browser (i.e. the user will be automatically redirected to the OpenAM login page upon invoking the vCloud Director login page). However, this process is only applicable through browsers (where redirection is provided) but not outside the browser.
I can't seem to find any means to perform SSO Login (by using the SAML assertion from the IDP for authentication). So far I've come across a dozen of references including the AssertionIDRequestUtil.sendAssertionIDRequestURI function from the OpenAM SSO, still, I'm not sure where to retrieve the AssertionId and SAML EntityId parameters.
Are there other means of getting the SAML assertion? Or maybe other ways to perform SSO Login?
I think the easiest way to achieve this would be:
perform authentication via REST or ClientSDK
use a Java HTTP client to kick off an IdP initiated SAML authentication flow (/openam/idpssoinit?metaAlias=/idp&spEntityID=entityID). When you send this request you need to make sure that:
the session id is part of the request as an iPlanetDirectoryPro cookie,
session upgrade won't be performed (your authcontext settings at the IdP will have a lower or equal authLevel, than the level the session was created with in the first step)