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?
Related
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.
I am trying to understand implementation of SSO system for service provider. Here are my questions.
User logs into System A. System A does authentication and displays a link to the user on page. When User clicks the link, System A redirects user to System B where System B is a 3rd party vendor. Who is IdP here and who is SP?
Is there any server to server communication in a flow initiated from IdP to SP? Is it required in all scenarios?
can you explain the data flow step by step in case of IdP initiated flow to SP?
Any material on this same or simple explanation will help.
In answer to your questions and assuming SSO via Security Markup Language (SAML):
System A is the Identity Provider (IdP) and System B is the Service Provider (SP).
There is no server-to-server communication. Information is passed via the client browser using HTTP bindings, for example HTTP POST.
Step by step IdP-initiated workflow (taken from OASIS SAML V2.0 Technical Overview):
If the user does not have a valid local security context at the IdP, at some point the user will be challenged to supply their credentials to the IdP site, idp.example.org.
The user provides valid credentials and a local logon security context is created for the user at the IdP.
The user selects a menu option or link on the IdP to request access to an SP web site, sp.example.com. This causes the IdP's Single Sign-On Service to be called.
The Single Sign-On Service builds a SAML assertion representing the user's logon security context. Since a POST binding is going to be used, the assertion is digitally signed before it is placed within a SAML message. The message is then placed within an HTML FORM as a hidden form control named SAMLResponse. (If the convention for identifying a specific application resource at the SP is supported at the IdP and SP, the resource URL at the SP is also encoded into the form using a hidden form control named RelayState.) The Single Sign-On Service sends the HTML form back to the browser in the HTTP response. For ease-of-use purposes, the HTML FORM typically will contain script code that will automatically post the form to the destination site.
The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the SP's Assertion Consumer Service. The service provider's Assertion Consumer Service obtains the message from the HTML FORM for processing. The digital signature on the SAML assertion must first be validated and then the assertion contents are processed in order to create a local logon security context for the user at the SP. Once this completes, the SP retrieves the RelayState data (if any) to determine the desired application resource URL and sends an HTTP redirect response to the browser directing it to access the requested resource (not shown).
An access check is made to establish whether the user has the correct authorization to access the resource. If the access check passes, the resource is then returned to the browser.
In SAML, is it possible to force the user to go through idp's login process everytime even when the user has an active idp session?
To make a concrete example here:
Let's call my application "SP"
I use SSOCirecle as idp and I use POST and redirect (SP initiated).
To test, I will first login to SSOCircle to get an active idp session. Then when I try going to SP, I should be redirected to idp.
Normally, since I already have an active idp session, the idp will see "oh, you already being authenticated before, you can go directly to SP!"
But I don't want that, I want idp to force the user to enter credential everytime, maybe by either (I guess)
ignore active idp session
don't create an idp session
I want to knwo whether this is doable.
Yes, the SP can send a flag ForceAuthn to the Idp in the AuthnRequest to require a new authentication instead of reusing an existing session.
As always with SAML2, you can't expect all Idps to support everything. Yyou have to test if your Idp supports the ForceAuthn flag.
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.
I have a site say www.e1.com. www.e1.com is Service Provider. Whenever I click a service in it, I am redirected to a Identity provider, say www.e2.com. Before that,In service provider(www.e1.com) I will check if any cookie is set for the user. For the first time there will be no cookie so it will send empty SessionId value. Thus, I am sending a SAML Request to www.e2.com along with with no id(as no cookie is set. Cookie contains Id)
Now in www.e2.com i.e.In identity provider,I will check whether www.e1.com has sent any Id value. If it is null I will create a session Id and store it in database(In www.e2.com). Then I will redirect browser to my Authentication page where User's Name and password will be asked and accordingly he will be authenticated. If the authentication is successfull, I will redirect browser to Service provider(www.e1.com) with SAML Response which contains session Id.
Now in Service provider the SessionId value will be stored in Cookie and browser will be redirected to consumer service page(service page the user wants to access).
Now if the same user wants to access some other service from same Service provider
(within the session), the browser will obviously send the SessionId in Cookie along with the request SAML. Identity Provider will check the SessionId value in his database, If its there in its database then it will give direct access to service to user without entering login credential as the user is already authenticated for the session.
Is this the right way to achieve Single Sign On with SAML? or
If this method has flaws, Can you explain those flaws?
Thanks in advance :)
Your understanding is not quite correct :)
Here is the flow:
User tries to access a protected resource on the SP. SP checks if the
user has a local (and authenticated session). If not it generates a
SAML <AuthRequest> which includes a random id. The SP then redirects
the user to the IDP with this AuthnRequest.
The IDP will check if the user has a local authenticated session. If
not it will authenticate the user The IDP will send an AuthResponse
back to the SP with an inReplyTo attribute which matches the id sent by
the SP in it's AuthnRequest
The SP will then create a local session. Subsequent requests to the
SP will not involve the IDP unless a) The session expires or b) the SP
receives a SingleLogout message from the IDP