In SAML, if the SP sends a RelayState parameter during an SP-initiated SSO login, the IdP (OneLogin) should send the RelayState back exactly as the SP sent it. This can be used to navigate to a particular page, etc.
However, OneLogin doesn't seem to be sending it back. When configuring a OneLogin app, the configuration has a field called RelayState. I've never needed it before now so I've left that empty thinking it's is the 'default' RelayState in case the SP doesn't send one or in case its a IdP initiated login but this doesn't seem to be the case.
Is there a way to get OneLogin to send back the RelayState the SP sent during an SP-initiated login? Do I need to add some variable/tag in this RelayState app configuration field? As an aside, even if I put something random in the RelayState field OneLogin is not getting sent to the SP even on an IdP initiated login (so maybe I need to turn it on somewhere I'm not seeing).
I tested here using our SP application and OneLogin without any issues. The relay state included with the SAML authn request was returned by OneLogin with the SAML response.
My understanding is that the relay state that can be configured in OneLogin is for IdP-initiated SSO only. I've left this blank. There was no special setting required in OneLogin to get it to correctly return the relay state as part of SP-initiated SSO.
Are you sending the authn request using HTTP-Redirect or HTTP-Post?
Either should work. I suggest double checking the RelayState parameter is included correctly with the authn request.
Related
I am implementing front-channel SAML 2.0 SSO golang Service Provider, with Okta as my Identity Provider (this is just a POC and should eventually work with any IdP).
Implementing the sign on process was straightforward with saml2 package. I've created the login endpoint that redirects to the SAML application login URL at the intended IdP, as well as the POST callback endpoint which is properly receiving the SAML assertion and is able to validate it. After that a session with a random cookie is created with the same TTL as the Identity Provider session TTL. So far everything works well (I haven't implemented Single Sign-Out yet, but I'm planning to).
However, when some time passes and the session expires, I'd like to renew it only if the user is still logged in with the Idp and hasn't been removed from the SAML Application. I would like to avoid redirecting the user to perform SSO again with IdP, because it would mean that if they are still logged in, they would be redirected back to the home page of my application. I wasn't able to find great sources on my options to go about it online.
Questions:
1.1 One solution that comes to mind is storing the requested URL in the RelayState parameter, whenever the session has expired, then redirect the user to the IdP SSO URL. When the redirect returns to the SAML callback POST endpoint, check the RelayState parameter and if set, redirect back to that (original) URL. That means that for users that use the system continuously, I would have to request Assertions very often. Does that make sense?
1.2 A second solution that comes to mind is to implement a back-channel of communicating directly from my SP to the IdP. That would allow me to verify a user is still logged in 'behind the users back'. If that's a sound idea:
a. Do I need to have dedicated code for each IdP?
b. Do I need to load an API key to the IdP which would allow secure communication?
c. Do I need to upload a public certificate to the IdP that would be able to verify that my SP signed the requests?
Will using the Assertion to get an OAuth 2.0 Access Token help me in achieving this?
I've chosen SAML 2.0 for now, since the environment is an enterprise oriented one and I thought it fits well with it based on what I read. Would using OpenID Connect instead help achieve my goals easier and fit well with enterprise oriented products?
I started with Service Provider based SSO for SAML. Since the user had to enter his email before proceeding with the login, a state variable was initiated and passed on to the SSO. It comes back through the callback URL and hence was check again for the sanity purpose. It protected against CSRF attacks.
Now IdP initiated SSO doesn't allow me to set state variable at all. Login starts at Identity Provider and only an auth token is provided to the app. I do not know which user is authenticating from the beginning. If I remove the state variable check, it could trigger a CSRF attack as well.
I am also using omniauth in rails which makes state variable a compulsory param and SSO provider is auth0.
What is the way to attach state variable to IdP initiated SSO solutions?
The de-facto standard value of the RelayState parameter in IDP-init-SSO SAML flows is the URL that you want to send the user to after successful validation of the SAML assertion at the SP. That would work for the vast majority of SAML deployments out there.
However, that mechanism indeed does not protect against CSRF attacks this is why the spec is silent on the value of RelayState in IDP-init-SSO and leaves it open to agree on mechanisms between IDP and SP to prevent CSRF through the value of that parameter. One such mechanism would be to use a signed value in the RelayState but as said, nothing is standardized and it would thus depend on a bi-lateral agreement between IDP and SP which does not scale.
In summary: send the value of the URL that you want the user to go to as the RelayState value in the "unsolicited" SAML Response that you send to the SP. How you get the IDP's SAML stack to do that is implementation specific. For Auth0 you can read on this at: https://auth0.com/docs/protocols/saml/saml-configuration#idp-initiated-sso, and in your case it would look like:
https://{accountname}.auth0.com/samlp/YOUR_CLIENT_ID?RelayState=http://FINAL_DESTINATION_URL
I am trying to understand SSO using SAML. I have come across the RelayState parameter and am very confused exactly why it comes first in SSO to send encoded URLs? What exactly does it mean?
Please read the following from the Google Developer documentation:
Google generates a SAML authentication request. The SAML request is encoded and embedded into the URL for the partner's SSO service. The RelayState parameter containing the encoded URL of the Google application that the user is trying to reach is also embedded in the SSO URL. This RelayState parameter is meant to be an opaque identifier that is passed back without any modification or inspection
The original meaning of RelayState is that the SP can send some value to the IDP together with the AuthnRequest and then get it back. The SP can put whatever value it wants in the RelayState and the IDP should just echo it back in the response.
This RelayState parameter is meant to be an opaque identifier that is passed back without any modification or inspection
There is also another, de facto standard use for RelayState when using Idp-initiated log on. In that case, there is no incoming request from the SP, so there can be no state to be relayed back. Instead, the RelayState is used by the IDP to signal to the SP what URL the SP should redirect to after successful sign on. In the standard (Bindings 4.1.5) it is stated that RelayState "MAY be the URL of a resource at the service provider."
It looks like Google is using RelayState for the target URL even on SP-initiated sign on, which is perfectly fine. But the IDP should, as the documentation says, just relay it back.
RelayState is an identifier for the resource at the SP that the IDP will redirect the user to (after successful login). It is a way to make the process of SSO more transient to the user because they are redirected again to the same page they originally requested at the SP.
As per official SAML document,
Some bindings define a "RelayState" mechanism for preserving and conveying state information. When
such a mechanism is used in conveying a request message as the initial step of a SAML protocol, it
places requirements on the selection and use of the binding subsequently used to convey the response.
Namely, if a SAML request message is accompanied by RelayState data, then the SAML responder
MUST return its SAML protocol response using a binding that also supports a RelayState mechanism, and
it MUST place the exact RelayState data it received with the request into the corresponding RelayState
parameter in the response.
This below flow diagram may help you step by step. ACS URL and relayState both are different. relayState gives you one more info/url to handle where exactly user want to go. more details
I am working on SAML2.0. One of our clients(IDP) requested us (SP) to have SP initiated requests without sending AuthnRequest.
Instead of sending AuthenRequest they have asked us(SP) to send a parameter on the URL that can tell them that the request has come from the designated SP. Is it an industry standard to implement SP initiated requests without having AuthnRequest parameter?
I would actually call this IDP initiated, as from the viewpoint of SAML, the IDP sends the first message. IDP initiated is part of the standard, so it does not break SAML.
But if you are going to have the SP tell the IDP to start authentication I would consider it bad practise not to have the SP start this by using a SAML AuthnRequest.
This would be a more interoperable approach making it easier to use standard SAML product without the need for customizations.
No it's not. However, from our experience, some IdPs do not support SP-initiated SSO. Instead, they require a redirect to the IdP including a parameter that identifies the SP. This then will trigger IdP-initiated SSO to the SP. This is not covered by the SAML v2.0 specification and therefore the format of the URL including the parameter name etc is not standardized.
I suggest double checking with the IdP to see whether they do support SP-initiated SSO as per the SAML specification. Perhaps they simply haven't enabled this support. If they don't then you're only option is to use this non-standardized approach.
Scenario:
Browser(User) requests resource from Service Provider (SP).
SP Redirects (with SAML Request) to Identity Provider (IdP).
Since it is first login, User gives the (IdP) his/her valid credentials.
IdP then redirects Browser (with SAML Response which includes SAML token) to the SP page.
I have two questions:
A. In Step 4, does the Browser store or cache the SAML Response and/or SAML token?
B. If yes, what kind of things (attributes? timeouts? protocols?) prevent me from taking that stored SAML token. Then coping it over to another computer (with a new session) and using that token to Login to the same SP?
The answer is "sort of" re caching. In your scenario, the Response will be sent via POST to the Service Provider from the browser. So the browser can "cache" the POST data that contains the SAML Response. So, just like any other POST event in browsers, if the user were to use the back button enough times after logging into the SP to get back to the POST event, the POST data could be resent to the SP.
There are a few things that help keep the Response from being hijacked -
Use of HTTPS between all parties
SP enforcement of NotBefore & NotOnOrAfter attributes
SP enforcement of one time use criteria (the SP must ensure that Response is not re-used during its validity period. If the message is received outside the validity window, then the SP should discard the message)
The IDP usually stores a session cookie on the client browser identifying the SAML session. The theft of this session cookie is probably no more protected then any other session cookie.
Using HTTPS in communication between SP and IDP will provide a great deal of protection from session hijacking.
For question A, it probably depends on the browser that you use.
For question B, there are several mechanisms that prevent the SAML response from being reused:
SubjectConfirmationData has attribute NotBefore and NotOnOrAfter that specify the time frame that the SAML assertion is valid. Thus, the SAML assertion cannot be used outside of this time frame.
SubjectConfirmationData has attribute InResponseTo that specifies the SAML request for which the SAML assertion is issued. Thus, the SAML assertion cannot be used for other SAML request.
SP must ensure that the SAML assertion is not replayed by maintaining a set of used SAML assertion.
You can read Section 4.1.4.3 and 4.1.4.5 of SAML Profiles specification.
I know this old, but the answer is yes the browser stores the SAML Token as a Cookie. (Typically) You can see it in your Browser's Cookie list, through various traffic/session inspectors like Fiddler, SAML Tracer on FF etc.