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
Related
I have a sample application created using node js and passport saml strategy for testing SSO with pingFed.
I intend to use SP initiated SSO and created my SP connector in pingFed.
I can successfully login using pingFed and Directory server. However what I observe is every time I try to hit login URL from same browser session I get login prompt. As per my understanding PingFed will create PF cookie and track session and will not prompt me for login.
As verification I verified that my first redirect request http:///idp/SSO.saml2?SAMLRequest= is without PF cookie.
Subsequently when I am hitting /login in my domain , above redirect happens with PF cookie set in request. In spite of that I am always getting login dialog. I am expecting pingFed to use PF cookie and should not try to re-authenticate the user but should exchange SAML token as user already has session established and it is identified by PF cookie.
Is there some gap in my understanding?
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.
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?
Method 1
Browser is directed to Service provider. Service provider checks whether there is any cookie set, If no then it redirects browser to Identity provider and Identity provider(IdP) validates user and redirect a ID to Service Provider(SP). SP takes that ID and set it as session cookie in browser and redirects user to service. Next time, if user asks for service again in same session the SP checks for cookie and redirects directly to service.
Method 2
Browser is directed to Service provider. Service provider redirects to IdP. IdP checks for its cookie and if cookie is not present,IdP authenticates user and set session cookie in browser. Redirects positive response to SP. SP redirects user to service. Next time user asks for the service within the session, Browser is directed to Service provider. Service provider redirects to IdP.IdP checks for its cookie and if it is present,it sends positive response to SP.
I am pretty sure that Guanxi implementation of Shibboleth (SAML2 profile) and almost sure that Shibboleth itself can be simplified to your "method 1".
You better check some of existing SAML2 profile implementations.
I don't believe either of those are valid SAML implementations. Usually in SAML identity information is communicated in a HTTP POST or through SOAP web service (see: http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language#SAML_2.0_bindings). Cookies are not used to 'authenticate' a user.
We have a web application that uses SAML 2.0 XML communicated in a HTTP POST to authenticate the user. Our customer's employees go through the identity provider on their side of the firewall to access our application.