I am working on SP initiated saml sso and it is completely new to me. I have gone through lots of articles and videos(wikipedia, centrify chalktalk, medium posts) but i am not able to understand some of the things:
Is the saml assertion the SAML token? if not, then how is it generated?
Suppose i have a saml based IdP and two saml enabled SP. Now in a purely post binding, when i login to one of the SP and then login to the second SP, How does the second SP log me in? To be more precise, how does the second SP know that the user is already logged into first SP? What is that parameter(s) that decides it? (can i get more low level explanation on this).
Does the IdP store data in cookie about the session or is there something else that i am missing out.
If there are any articles based on this please do post them.
Thank You.
Let me first answer your specific question points:
1) Is the saml assertion the SAML token? if not, then how is it
generated?
-This is all just terminology for the same thing. A SAML Assertion and a SAML Token are the same thing. There are 2 different SAML assertions/tokens that are important for you to focus on. The SAML Request and the SAML Response. The SAML Request is what is sent from the SP to the IDP in SP initiated SAML SSO. The SAML Response is what is sent from the IDP to the SP as the final part of SP initiated or during IDP initiated SAML SSO. SP initiated is when the user starts at the SP app, is redirected to the IDP for authentication, and then sent back to the SP app by the IDP. IDP inititated is when the user starts at the IDP, and goes right to the SP. A SAML Assertion is just XML that has been signed, converted to a string and base 64 encoded. they are redirected with the user from SP to IDP and back.
2) Suppose i have a saml based IdP and two saml enabled SP. Now in a
purely post binding, when i login to one of the SP and then login to
the second SP, How does the second SP log me in? To be more precise,
how does the second SP know that the user is already logged into first
SP? What is that parameter(s) that decides it? (can i get more low
level explanation on this). Does the IdP store data in cookie about
the session or is there something else that i am missing out.
-This is specific to your IDP. As a Centrify SME, I can tell you how Centrify and similar IDPs work. When a user signs into the IDP, whether its from an SP initiated redirect, IWA on their corporate machine, or directly to the IDP itself, a cookie is added to the browser. In the case of Centrify, this cookie is called .ASPXAUTH. Every time a user is taken to the IDP after logging in, they are not prompted to log in again. So if a user starts at SP1, gets redirected to the IDP, logs in, and is redirected back, the cookie has been set by the IDP. Now if they go to SP2, by default that SP would also redirect to the IDP, but the IDP would not prompt for auth again because of the set cookie. So the user wouldn't notice the redirect and the IDP would just send them right back to SP2 with the appropriate SMAL response. So Like this:
SP1 > SAML Request and redirect to IDP > Log in to IDP and cookie is set> SAML Response and redirect back to SP1 > Navigate to SP 2 > SAML Request and redirect to IDP > Cookie is set so immediately redirect back to SP with SAML Response.
Centrify also has API's that can be used by SP's. For example, an SP could do a client side API call to /security/whoami to see if there is a valid ASPXAUTH cookie in place. So SP2 could check for a valid cookie and decide to to redirect at all because the cookie has already been set. https://developer.centrify.com/reference-link/securitywhoami
Hopefully this helps. I wrote a very basic example of this in c# while at Centrify. You can find the code here https://github.com/centrify/CentrifySAMLSDK_CS. Feel free to reach out here with more questions or find me on twitter https://twitter.com/NickCGamb
Yes, the Assertion is normally a fully portable token by itself, but there are ways to bind it to for example keys on the requester.
The second SP does now that the user is already signed in. The SP will redirect the user to the IDP with an authentication request to the IDP. IDP usually saves a cookie for the user when it authenticated the first time, this is not specified by SAML but generally how its done. When the user arrives at the IDP the IDP looks at the cookie and if the user authentication is still valid the IDP automatically sends a valid Assertion/token to the SP. It is possible for the SP to overide this behaviour by specifying the ForceAuthn attribute in the authentication request.
As for resources I would recommend the SAML Technical Overview from OASIS http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf
Related
When using SAML2 to perform a Service Provider (SP) initiated authentication, a secret ID is generated by the SP and the added to the the Authentication Request. The Identity Provider (IdP) responds to this AuthnRequest and echoes the secret ID of the SP ("in response to") to ensure coherence of the Authentication Request/Response. The authentication at the SP can then proceed (after verifying a whole lot of other things).
What happens when the current authentication session at the IdP is still valid and the "IdP Portal" is equipped with the ability to redirect to the SP by some sort of bookmark/link such as application icons in Office356. Is there any provisioning in the SAML2 standard to continue the formerly initiated session at the Service Provider (a IdP session id of some sort)? It would be odd if a re-authentication would be necessary in this case because the current session is still active (I wouldn't think this falls into the category of IdP initiated authentication).
The IdP hits the ACS endpoint when this app icon is clicked, but I'm not sure where to look in the Authentication Response (according to SAML2 spec and more specifically in an Azure AD IdP response). Any help would be appreciated.
When "federating" identities, the session handling is entirely up to the individual systems. There is no real mechanism within the protocol to tie those separate sessions together. The Identity Provider (IdP) can inform the Service Provider (SP) of the length of time that the SP can consider the identity assertion "valid", but that's about it. Typically, if the identity being authenticated has a session at the IdP, then the IdP will just issue the assertion. When the user is redirected back to the SP, if they had a session there, then it's up to the SP if they allow that session to continue.
In order to tell the two types of assertion apart, the following guideline can be used.
For IdP-initiated, the RelayState attribute will generally have a URL of where the User wishes to be sent at the SP, after the SP consumes and accepts the assertion from the IdP.
For SP-initiated, when the SP starts the authentication process, it will insert an opaque ID in the RelayState attribute of the AuthnRequest. The IdP must use that same ID in the Assertion's RelayState field (and the same ID usually ends up in the InResponseTo field as well).
So, that's a whole lot of words to say "The handling at either end, IdP or SP, is determined solely by that end (though maybe there's some conversation about how the ends handle them)."
Is the SAML request sent everytime to the IdP whenever some authentication is required or is it first checked in the session stored in the browsers cookies and automatically authenticated if the session is found ?
To get access to a web application (SP) you generally need to present something to it to prove you are entitled to access it. Usually this entitlement is a username/password combination. Once the SP verifies your entitlement (compares username/password with db perhaps), it generates a session for you that is time limited according to the SP's policy.
When you access the SP using SAML, you have no username/password. In this case, your entitlement comes from your attributes which your IdP releases to the SP. Once the SP verifies your attributes it generates your session, which is exactly the same type of session you'd get from a username/password verification.
There are a number of ways the SP would ask the IdP for attributes again:
The SP's native session expires and your SAML attributes have expired (they have a time to live).
Your SAML attributes have expired. This might be the case in a high security SP where you may only have clearance for an hour perhaps. Your SAML attributes may only have a TTL of one hour. The SP would then ask for your attributes from your IdP to refresh your entitlement.
If the SP's native session expires but your SAML attributes are still valid it may choose not to ask your IdP but to create a new session based on your current SAML attributes. It all depends on the security policy of the SP.
If you go to another SP, you generally don't have to authenticate at your IdP again as your IdP may have a session for you after the login for the first SP and will just release your attributes to the second SP.
Typically the SP stores a session when the user is first authenticated to that SP. If the SP needs to authenticate the user it first looks for a local session. However if a user has a session at one SP and then tries to access resources at a second SP, then this SP will not have the local session from the first SP and will need to send a authnrequest to the IDP.
As far as I remember this ia not regulates in the SAML spec but it is generally how things are done.
As per SP initiated SSO flow, User tries to access SP. Since the user is unauthenticated, he is redirected to IDP where he enters his credentials, post successful login, IDP sets cookies in user's browser(under IDP's domain) and redirects the user back to SP with SAML response. Once SP verifies SAML response it creates it's own cookie/token and sets in user's browser under sp's domain.
What should ideally happen in subsequent requests :
Should SP rely only on it's own cookie to fetch user info
Should SP validate user session with IDP in every request.
If option 1 is advised, Is it ok from security point of view as post login there is no communication between SP and IDP for further requests.
If option 2 is advised, there would be an overhead to call IDP in every request which might impact performance of the SP.
Please suggest what should be the ideal flow here.
If option 1 is advised, Is it OK from security point of view as post login there is no communication between SP and IDP for further requests.
[ME] Yes, it should be the responsibility of SP to validate the cookie(maybe encrypted with all the details in it or referenced through ID pointing to persistent storage area). IDP's job is to provide identity that's done already.
If option 2 is advised, there would be an overhead to call IDP in every request which might impact performance of the SP.
[ME] Yes, that would be too much to validate user session with IDP. The way it works is - If SP session has been invalidated or is being created, go to IDP, if IDP cookies/session is valid give SAML response/assertion Or authenticate if not and finally SP creates a new session.
HTH.
So the user has been authorized/authenticated by the identity provider. Are you afraid that this authorization/authentication might suddenly expire? For example, maybe the IdP belongs to the user's employer, and when the user is fired it is critical that access to the SP is revoked immediately as well? Of perhaps the user finds out that his credentials have been stolen and therefore closes/blocks his IdP account, do you want to be able to stop your SP session as well? You can only do these things in Option 1, so this is the more secure option.
As you rightfully say, that comes with a lot of overhead. So the question is basically, how important is it for you that your SP session gets terminated immediately once the user's IdP account gets revoked.
By the way, what I don't like is that the IdP is storing the session in a cookie. In my opinion he shouldn't do that, especially not if you implement option 2. The reason for that is that this makes logging out very tricky: the user should now remember to log out at both the SP and the IdP, while he only needed to log in once.
We've got a web application running in a WebSphere App Server 8.5.5 environment that we're currently authenticating against a database table. We're now changing things to authenticate with SAML against an ADFS IdP. Here's the rub: some users might not exist in the ADFS (the AD behind the ADFS). So the scenario I believe we want is either:
1) If we receive a SAML response with failed authentication, fallback to form-based authentication
or
2) Somehow have 2 entry points into the application, 1 SAML-driven and the other starts with form-based login.
Has anyone come up against this same scenario, and are either of the above possible solutions workable in WebSphere 8.5.5?
In WebSphere SAML service provider (SP) implementation, upon detecting received SAMLResponse is in valid, SP redirects user to a pre-configured login page (start a new SSO), or an error page. Doing this can sure user is always authenticated by SAML IdP, and authenticated subject always contains SAML for propagation and other post processing.
SAML SP supports filter, and only accept requests that satisfy conditions defined in filter. You can define filter condition that should be ignored by SAML, and you can use URL pattern, or any http header name as filtering condition.
If filter can not meet your requirement, we could further evaluate other options.
I have a product which authenticates using Shibboleth.
When a user initiates a logout on the website
The web server sends a logout request to the Shibboleth SP.
SP deletes the cookies post on getting the request.
However if the user goes back to the website the login page is not prompted
For the configuration shown below I am using Shibboleth Service Provider given here
https://www.testshib.org/install.html#SP. It is configured to use the testshib.org IdP details of which can be read here
I believe that the IdP is not deleting its session cookie and re-login the user on Step 3.
More on IdP Cookies:
This wiki-source states IdP uses two cookies _idp_authn_lc_key which is deleted after authentication. and the second is a session cookie '_idp_session' for which it states that :
Once a user has been authenticated they will have a long-lived session
with the IdP which is tracked by a cookie named _idp_session. This
cookie contains only information necessary for identifying the user's
IdP session. This cookie is created as "session" cookie and will be
removed when the browser chooses to remove such cookies (often when
the browser is closed).
My question is
What changes do I need to make on the SP to request the IdP to delete the same and effectively create a GLOBAL LOGOUT ?
For what it's worth, you're going to have a very hard time forcing the IdP to log the user off. The cookie approach is an implementation detail, and not all IdPs use it, and it could change. Some IdPs may offer a logout URL, but honestly, it's potentially something bad for users (can you imagine if you could figure out a way to constantly deauthorize a user from not just your site, but their sessions with any other SPs?). You really only have control of your own sessions on the service provider.
Why not force re-authentication when your user returns / comes back to your SP? If they haven't been authenticated recently to the IdP after a visit (that's a field you get back from the SAML exchange), just send them back to the IdP again and pass the forced-reauth flag.
If you're using the Shibboleth software, it's even built in:
https://wiki.cac.washington.edu/display/infra/Configure+a+Service+Provider+to+Force+Re-Authentication