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.
Related
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.
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 am creating simple service provider (SP) on java with wso2 saml sso authorization.
I implemented it in this way (please correct me, if I'm wrong):
User inputs some target Url in browser
My SP's servlet sends redirect to WSO2 IDM.
IDM authorizes the user and redirect to my Consumer Url with
SAMLResponse and RelayState parameters.
Now SP must process this request and redirect user to target Url without redirection to IDM again. Otherwise I'll get the infinite loop, so I think that between step 1 and step 2 should be one more step...
What is the proper way to do this?
Typical implementation
1 User tries to access a protected site
2 A filter checks if the user has an authenticated session.
2.1 If not, redirect to IDP/IDM
2.1.1 IDM authenticates user and redirects back to SP with identity proof
2.1.2 SP creates authenticated session
2.1.3 User is redirected to target URL everything start from 2 again.
Here I have a post describing the flow in more detail
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)
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