We are implementing SAML integration and I am the service provider and my identity provider is asking me to send "SAML Consumer URL" and "RelayState"
I would need help to understand what is SAML consumer URL & RelayState and how do I get/generate it for my application.
Thank you for your time and help!
TLDR, AssertionConsumerUrl (ACS) endpoint is SAML protocol endpoint, RelayState is like cross-domain cookie, used to coordinate messages and actions of IdPs and SPs.
In 5.1.Web Browser SSO Profile of SAML 2.0 Technical Review, it will give you a general understanding of how the flow goes.
Down to the SSO implementation, for example Shibboleth, this FlowAndConfig doc details the SSO flow pretty well.
In 2. SP Determines IdP and Issues Authentication Request:
Cookie Set by SP
During this step, the SP will preserve the original
resource requested by the browser using a "relay state" mechanism,
which is configured by a relayState property on the <SessionInitiator>
element. The default mechanism does not rely on a cookie any longer,
but many systems do, and send a state management cookie containing the
resource URL to the client along with the request prepared for the IdP
or DS/WAYF.
In 5. Back to the SP:
The browser delivers the response from the IdP to an Assertion Consumer Service endpoint at the SP.
relay state info returned from IdP to SP
Cookie Read by SP
The "relay state" information returned by the IdP, if any, will have
been created by the SP and if using a cookie, will point to a
specially named cookie that should accompany the authentication
response supplied to the ACS endpoint in this step. This is the cookie
set in Step 2 above. If this cookie is missing (or if no relay state
exists at all), the associated application's homeURL property is
substituted as a fall back.
Also, Shibboleth has some wiki for those two terms as well.
AssertionConsumerService concept
RelayState concept
Hope it helps!
Related
I have custom policies setup within our Azure AD B2C tenant to setup a SAML based signin SP initiated flow. On receipt of the response from the third party IDP I get the exception "The response has an invalid relay cookie".
I believe this is because the IDP's response is missing the InResponseTo property. Having spoken to said IDP, they are not able to send back the InResponseTo property in their response.
Is there a way to either remove the InResponseTo property from our initial request, OR is it possible to disable checking the InResponseTo attribute on receipt of the response?
I've successfully run a signin using the same custom policies in B2C, but using https://samltest.id/start-sp-test/ as the IDP instead, and can see the InResponseTo property returned in the response from here. So this is the only thing I have been able to identify as the a possible cause.
I know this is bad practice / a security flaw, but we are trying to prove we can get the identity flow working with this third party, with a view this will be fixed at a later date.
We are trying to implement SSO, using OneLogin as the IdP with our Cisco Call Manager cluster using a single agreement for all the servers in the cluster.
This just basically means that our metadata file contains a separate AssertionConsumerService tag for every server in the cluster.
However we are hitting an issue where in the SAML response the Destination is not recognized as valid.
My question would be, in the case of multiple ACS' used, what would the destination field need to look like in the SAML response? Does the IdP need to recognize which consumer the request came from and dynamically change the destination in the response to be the correct one for the specific consumer?
Right now the SAML response looks something like this:
<samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Destination="https://<CUCM_2>:8443/ssosp/saml/SSO/alias/<CUCM_2>https://<CUCM_2>:8443/ssosp/saml/SSO/alias/<CUCM_2>https://<IMP_1>:8443/ssosp/saml/SSO/alias/<IMP_1>https://<IMP_1>:8443/ssosp/saml/SSO/alias/<IMP_1>https://<CUCM_1>:8443/ssosp/saml/SSO/alias/<CUCM_1>https://<CUCM_1>:8443/ssosp/saml/SSO/alias/<CUCM_1>" ID="pfx117d2cec-f554-1fba-ff86-8db77b497e35" InResponseTo="s2ded98fb1a7423ea7bb1fcc95cf5c57ae3bf19684" IssueInstant="2019-02-18T16:06:06Z" Version="2.0">
and we get the same jumble for Recipient attribute in SubjectConfirmationData
With a proper cluster, you'd have a single ACS URL and the cluster would manage the user session between cluster members outside of SAML. I've not heard of multiple ACS URLs being used for a single SAML supporting SP. The IdP ( Onelogin ) needs to know specifically where to send the SAML response. I think you'll need to look at your cluster configuration and see whether it can be configured as a endpoint regardless of the cluster instance that initiates the SAML request.
Ah, but Cisco is special, don't you know? :)
I managed to get it working in the meantime and whoever is reading this thread in the future, I can confirm that OneLogin can now support Cisco clusters using a single cluster-wide metadata. But for any other IdP the setup is:
IdP requirements
CUCM only supports NameIDFormat as transient
HTTP-POST and HTTP-Redirect SAML bindings need to be enabled
SAML specification that allows for the definition of multiple AssertionConsumerService tags needs to be supported
Operation
When setting up SSO, within the metadata generated by CUCM if using cluster wide SSO mode, multiple AssertionConsumerService tags are defined. Two for each server in the cluster, one using the POST method and one using Redirect. Each ACS also has an Index tag, that starts at 0. This is sent to the IdP
When trying to authenticate a SAML request is sent to the IdP, within the request the AssertionConsumerServiceIndex field is set to the Index of the server from which the request was generated, as defined in the metadata originally provided to the IdP
The IdP then sends back a SAML response, in which the Destination and Recipient tags are set to match the Location tag from the metadata corresponding to the requesting server
I am trying to create a client that uses SAML, but I am not sure what the Master SAML Processing URL field should be.
I read the documentation, but its still not clear to me.
SAML uses assertions in order to verify resource accesses. The service provider needs to declare a specific url for this assertion exchange. On the other hand, there's the url which the Service Provider uses to manage the Single Sign Out process. The Master SAML Processing URL of Keycloak just lets you specify the same endpoint for both processes (you can still configure them individually using the fine grain configuration).
As an SP, we've opted for the POST binding option - it seemed to be the advised approach. SAML is now set up and working with the IDP. We would now like to change to Redirect as it is better handled in Ajax calls after timeout.
My question is whether we can switch from POST to Redirect without incurring a setup change on the IDP side. Seeing as both bindings are just using the UserAgent (browser) as a transport anyway, I figured it may be possible. But the binding is defined in the AssertionConsumerService in the metadata which indicates that IDP would need to be informed and have its configuration changed.
Sending a SAML Response (which is what is sent to an Assertion Consumer Service endpoint) via Redirect is not supported by the SAML spec since responses easily get too large to send as a query parameter. See line 420 in the SAML Web SSO Profile spec https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
Identity Provider issues to Service Provider In step 5, the identity provider issues a message to be delivered by
the user agent to the service provider. Either the HTTP POST, or HTTP
Artifact binding can be used to transfer the message to the service
provider through the user agent. The message may indicate an error, or
will include (at least) an authentication assertion. The HTTP Redirect
binding MUST NOT be used, as the response will typically exceed the
URL length permitted by most user agents.
You can switch to Artifact, though SP metadata will need to updated on the IDP to relay the changed endpoint.
We have an OpenSSO (OpenAM) instance set up at our end to work as a Service Provider (SP). It's been working well so far in an SP Initiated SSO scenario, however, I recently had to set it up for an IDP initiated scenario and am unable to get it to work successfully. To explain, in this scenario, the IDP would like to send the SAMLResponse directly to the Assertion consumer service at my end and our OpenAM instance should be able successfully digest the response and send the user to our underlying application. My questions are:
Is there any other configuration required in this scenario except for exchanging/uploading the metadata between the IDP and us (SP)?
Can I upload the metadata of the iDP in the same COT as the other IDPs that are currently working in the SP Initiate Scenario? Or should there be a new COT for each IDP provider?
What URL should I provide to the IDP to send the SAMLResponse to? Is it the AssertionConsumerService index="1" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" from our metadata? I tried this a few days back and OpenAM reported an error - "this is not the right consumer service for this request" or something.
I got an answer for this on an OpenAM forum -
http://lists.forgerock.org/pipermail/openam/2012-August/007872.html