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)."
Related
I have an app where we take care for the authentication, meaning - we store the usernames and their passwords.
Now, I want to add an SSO option to the app.
Obviously, for normal user, the password field on the User model is required. What is the best practice regarding users coming from SSO login? (they must be saved in my db anyway, but do not have password)
**The app is written in RoR with devise and devise-saml-authenticatable (with Azur AD as my IdP) but my question has no relation to it.
They don't have a password that you have access to... that's the point of single sign-on, the identity provider handles all of that. You tagged SAML, so I'll speak to that, but this is broadly true for other SSO systems.
You are the Service Provider (SP). They get redirected from the Service Provider (your app) to the Identity Provider (IdP), log in, and are returned to your application with a SAML Assertion. Because there is a trust relationship established between the SP and IdP, you inherently trust the assertion from the IdP (so long as the certificates, etc.), so the user doesn't need to provide you with a username. Their "credential" is the SAML assertion.
Since the password isn't needed, it doesn't need to be set. If your DB schema requires that field be non-null, alter your schema, or load it with random data when you provision their access.
Note: SAML is for authentication, not authorization.
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
Trying to implement OpenId Connect in Web Application consisting of following components
Identity Provider
Resource server
Single Page Application acting as Client.
Identity Provider and Resource Server are the same application.
SPA use Password Flow to get access_token and stores into the cookie. Storing access_token into cookie has it's security threads, but's it's a different story.
Problem
access_token issued by IdP is expired after 30 min and SPA needs to renew token without asking users for credentials again.
Solution
IdP returns refresh_token along with access_token. Whenever SPA gets 401 from Resource Server, it sends refresh_token to IdP and get's new access_token back.
Problem
Sending refresh_token to SPA is bad practice.
A Single Page Application (normally implementing Implicit Grant) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.
Suggested solution
When the Access Token has expired, silent authentication can be used to retrieve a new one without user interaction, assuming the user's SSO session has not expired.
I think Silent Authentication is not applicable to Password Flow when IdP and Resource Server is same application. access_token issued by IdP is only piece of information which can be used to authorize against Resource Server/IdP after its expiration, how a client can convince IdP to issue new access_token? (without sending refresh_token)
Found angular-oauth2-oidc library which uses refresh_token to renew access_token.
What is best practice/solution in this case to renew access_token?
technical details
Identity Provider - ASP.NET Core + Openiddict library.
SPA - AngularJs application.
Single page applications must not receive refresh tokens. That has been established rules in OAuth 2.0 and OpenID Connect.
One good option I see here is to use Implicit Flow. This will establish a front channel session from your browser to Identity Provider. With password grant type you do a back-channel call (POST), so you don't get such session.
Usually this is a cookie which points to information about previous logged in status (these are identity provider specifics). With completion of the flow, SPA will receive the access token. As you figured out, it will expire. But once that happens, SPA can trigger another implicit flow, but this time with prompt query parameter.
prompt
Space delimited, case sensitive list of ASCII string values that
specifies whether the Authorization Server prompts the End-User for
reauthentication and consent. The defined values are: none , login, consent and select_account
If you identity provider maintain a long lived session (ex:- few hours or days) or if it maintain a remember me cookie, SPA could use prompt=none making it to skip login step from identity provider. Basically, you are getting browser based SSO behaviour with this.
Using the Resource Owner Password Credentials flow defeats the refresh token storage argument: instead of not being able to store the refresh token in a secure place, the SPA would now have to store the Resource Owner credentials in a secure place (assuming you want to avoid requesting username/password from the user frequently). The Implicit grant was designed for usage with an SPA, so it is better to stick with that.
Further to previous answers, the latest OAuth working group guidance for SPAs no longer recommends use of the implicit flow.
If you have simple, shared domain app (IdP, RS and client on a single domain) then you should consider not using OAuth at all. From the doc:
OAuth and OpenID Connect provide very little benefit in this
deployment scenario, so it is recommended to reconsider whether you
need OAuth or OpenID Connect at all in this case. Session
authentication has the benefit of having fewer moving parts and fewer
attack vectors. OAuth and OpenID Connect were created primarily for
third-party or federated access to APIs, so may not be the best
solution in a same-domain scenario.
If you are using OIDC/OAuth in a SPA, they recommend the auth code flow with PKCE.
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.