I have a Salesforce IdP initiated authentication and authentication works well, but now I need to use RelayState to navigate deeper into the .NET app.
I am using the Sustainsys MVC library and cannot find an example how to
retrieve the RelayState parameter. The Sustainsys documentation has only one mention of RelayState. How do I retrieve the RelayState URL parameter?
Set the property IdentityProvider.RelayStateUsedAsReturnUrl to true and the ReturnUrl will be used as the redirect Url after Idp-initiated sign on.
Related
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.
Unfortuantely the built in AEM SAML Utility does not support the HTTP Redirect binding (only post binding). I have to perform SAML authentication to an external IDP which has HTTP redirect for both single sign on and single logout. Because of the AEM limitation I would like to configure ADFS to handle authentication with this external IDP and somehow get AEM to talk to that ADFS (either a federation service, or maybe an RP or claims provider). Does anybody know how this could potentially be achieved? I am assuming I could leverage the SAML utility or the SSO utility/modules in AEM (sling) to connect to ADFS somehow who will be responsbile to relay or proxy the IDP response to AEM. thanks
Using OOTB SAML Authentication Handler there is an option IDP HTTP Redirect, I was able to configure SAML authentication with a redirect to ADFS and then after giving credentials, IDP was redirecting back to AEM with SAML2 response containing all the data, however, that was handled by POST Binding.
EDIT:, OK, I have just noticed that IDP HTTP Redirect option is not present in linked official documentation however on the video in this tutorial you can see it available on AEM 6.1... I do not recollect now if the POST binding is used at the end so that please check first if that might work with this option as I have used that before.
If you would need other solution, the fastest option I see is checking the default implementation of SAML Authentication Handler by decompiling (it can be done following these steps, by at the same time I am only suggesting, not recommending that!) and base on it implementing custom handler adapted to your needs.
We have two relying party endpoints that customers can configure in ADFS 3.0 for SAML 2.0 SSO.
https://blah/saml2/mylink
https://blah/saml2/mylink?redirect=differentpage
When they click on both connections, they get taken to the "mylink" page. Is there something in the ADFS relying party field that cannot handle the "?redirect" syntax, so that it defaults to the "mylink" page?
In short, SAML 2.0 specification doesn't support redirect url like that. IdP (ADFS in this case) always returns the consumer endpoint which is /mylink in your case. A common trick is to use relaystate. You can set the relaystate attribute to the url you want to return after login, e.g. /mylink?redirect=differentpage. Please note that you will need to write code to do that redirection yourself after your application receives response from ADFS and finishes processing it.
I am trying to configure BIME Analytics as a service provider (SP) to use Google for Work as a SAML Identity Provider (IdP).
Following the instructions at https://support.google.com/a/answer/6087519?hl=en I am able to perform SP initiated authentication. This means if I visit https://.bime.io/portal and click the SAML login button, I am redirected to a Google login page and after entering my Google for Work credentials am able to access my BIME portal page.
Unfortunately, I cannot get IdP initiated authentication to work. That is, from Gmail for example, if I open the app launcher and click on the icon for my BIME SAML app, it will take me into BIME without any authentication issues, but then I get a BIME dashboard not found error.
BIME support was able to identify that this is because I was not sending a RelayState parameter value which they require. When I start in BIME, I'm on their webpage and there is a hidden RelayState value that is sent to Google to let it know where to send me after I log in. However, when I start in Google, that value is not set. BIME support was able to configure the connection in Okta because Okta has a "Default RelayState" field that they could hardcode a value into.
For Google SAML apps, how do I specify a default RelayState value to enable IdP initiated authentication into a SAML app?
Yesterday I took a look at the IdP SAML setup page in G Suite and noticed there is an optional "Start URL" field.
I also noticed in the help documentation to configure pre-integrated SAML applications that the "Start URL" field was frequently used.
Since the configurable parts of an IdP response are:
SAMLResponse With Assertion (including "Assertion Consumer Service URL" and "Entity ID" fields in G Suite config page)
RelayState parameter
I had to guess that the "Start URL" is likely the field to hold the RelayState parameter. Considering RelayState is an optional--but important and commonly used--part of the SAML integration this makes a lot of sense. It also explains why the field is optional, and directly below the ACS and Entity ID fields.
This Oracle blog post references the Start URL field and suggests one of its uses is to contain the unsolicited RelayState value:
Optionally enter a Start URL for Google IdP Initiated SSO operations,
where the user will click on the SAML Application partner at Google to
be redirected to the Application at OAM: this would be the protected
application URL, or unsolicited Relay State.
So while I can't test myself at the moment, I think it's safe to say this "Start URL" field is what you're looking for to set your RelayState value.
The relaystate URL you are looking for is
https://www.google.com/a/[DOMAIN]/ServiceLogin?continue=https://mail.google.com
More info here
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