I currently maintain an in-house SAML IDP written utilising LightSaml. This has served the company well for the last 2 years working with SP initiated SSO. I have recently been tasked with implementing IDP initiated SSO and I'm not able to work out how the user is automatically redirected to the desired protected page once they're authenticated.
In SP initiated SSO, the user starts at the page they want, therefore the SP knows where they want to end up after being authenticated. So in this case, the SP handles the final redirection.
In IDP initiated SSO, the SP doesn't actually know what protected page the user wants, so could someone explain what happens after the IDP sends the auth response to the SP?
Thanks in advance.
In IdP-initiated SSO, along with the SAML response, the IdP can send relay state. This relay state is the URL the SP should redirect to once SSO completes. If no relay state is sent, the SP will most likely redirect to some default page.
A typical scenario is that the IdP has a portal page with one or more links representing different pages at the SP. If the user clicks link #1, the IdP initiates SSO to the SP and sets the relay state to the page #1 URL. If the user clicks link #2, the IdP initiates SSO to the SP and sets the relay state to the page #2 URL.
Related
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.
I am implementing a SSO using SimpleSAMLPhp Service Provider.
I provided my metadata to remote Shibboleth Identity Provider and was provided a test account.
When a user visits a specific page on my SP, they get redirected to the IdP, login, and are redirected back to my web site with a bunch of IdP provided attributes. This part works.
This part I am struggling with.
If the user authenticates with the same IdP through a different Service Provider and then visits my page, how do I know they are already authenticated? Currently I am being asked to login again.
Is there a configuration value somewhere that lets me do this? Or am I using the wrong method? This is what I am doing.
$as = new SimpleSAML_Auth_Simple({REMOTE_AUTHSOURCE});
$as->requireAuth(); // this redirects to remote IdP login
$attributes = $as->getAttributes();
Thanks.
There are two separate authentication sessions to consider. One session is in you app and the other is at the IdP. The requireAuth method can tell if the user already has an authenticated session in your application, and will return immediately in that case.
There is no way for you to tell if a browser has a session at the IdP. You just call requireAuth whichs send the user there and if the IdP decides the user's session is still valid it will respond without prompting for login.
Are you saying that the user has a valid session at the IdP and they are being re-prompted to authenticate when you send the user there? That could be due to IdP policy, or if your app was sending something like 'forceAuth' in its AuthnRequest.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
In my understanding of SP-init and IDP-init SSO is as follow:
IDP-init SSO: A base64-encoded saml response is generated by IDP and send to SP, SP then verifies the response and finally the user is logged into the application if the response is valid.
SP-init SSO: A saml request is sent from SP to IDP, then IDP will authenticate the user then send back the saml response, the next part is same as IDP-init SSO.
How do we decide to choose whether the SSO is using SP-init or IDP-init ? SP-init seems to be more secure and reliable than IDP-init SSO because of the authentication part.
To me, the business requirements of the service provider's application tell you:
If all user interaction with the service provider's application will start at a "homepage", or default landing page, then IdP-initiated probably makes a lot of sense (less to break - no signed AuthnRequest needed).
If there are "deeplinks" that are provided to your users to things like reports via email (that is, a user can click on a link that should take them deep within the service provider's application), then SP-initiated is the only way forward.
In both instances, the user will be authenticated at the IdP based on the IdP's authentication rules - neither SP-init or IdP-init is "more secure" in that regard. The flows:
IdP-init:
User clicks link to start IdP-init SSO
IdP validates that User is authenticated - if not redirect for authentication
IdP converts authentication attributes (like username, email, etc.) into SAML assertion and redirects user to SP
SP converts SAML assertion to SP application token and redirects to application
SP-Init:
User clicks link to go to SP application
SP Application determines the user does not have a token and redirects to SP
SP redirects to IdP
IdP validates that User is authenticated - if not redirect for authentication
IdP converts authentication attributes (like username, email, etc.) into SAML assertion and redirects user to SP
SP converts SAML assertion to SP application token and redirects to application
The only difference, as you can see, is the first three steps.
You choose based on the desired or required navigation flow of a user (assuming browser POST binding based on your description).
If your requirements dictate the user start from secure (logged in) website A and navigate without password to site B, this is by definition IdP initiated.
If on the other hand the user is expected to be on an unauthenticated site yet log in with credentials from a partner site, this is where the SP initiated scenario comes into play. StackOverflow itself offers this style of sign in if you choose to log in with a Google account (though an alternative to SAML is used). The user starts somewhere on StackOverflow, clicks the login link, chooses their IdP (in SAML semantics) as Google, and are sent with an authn request to the IdP. After credential challenge of unspecified sort (eg your browser might already have an authenticated session at the IdP site, or the IdP might use two factor auth, etc) the user is returned to the SP site with a SAML response document.
SP-initialized is always to prefer. IDP-initilized will make work easier for the SP implementation but it comes with a buch of problems such as XSRF, interaoperability and deep linking.
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.
When the user is viewing the SP and he clicks the "Login" button, a popup pointing to the IDP's login form is opened. After the user provides their username/password and submits the login form within the popup, assuming the credentials are valid, how can I get the SAML assertion generated by the IDP back to the SP. Can I use window.postMessage?
The response (including the SAML assertion) of the IDP will be send to the Assertion Consumer Service URL of your SP. At this point you can do everything you want with it and assuming the SAML assertion is correct, create an authenticated login session at the SP level.
Depending on your use case you could now exit the popup and refresh (maybe partially) the parent window so it will pick up the logged in user. You could use the windows.opener object to call a function on the parent window. The main use of window.postMessage is to send data between window/frames across domains. But because your a receiving the response on a SP URL you should not need this.
Based on your story I am wondering if your are doing an SP initiated SSO by sending an AuthnRequest to the IDP?