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
Related
I have a saml response that gives me azure active directory when doing the process with saml 2.0, the whole process is done normally, I send a saml request and the azure active directory returns the saml response, to do the whole process I have based on this guide, I've been reading a bit and I've noticed that Azure AD in the saml response sends the values within this tag:
<xenc:CipherData>
<xenc:CipherValue>VALUE HERE</xenc:CipherValue
</xenc:CipherData>
And not inside:
<AttributeStatement><Attribute Name="IDPEmail"><AttributeValue>administrator#contoso.com</AttributeValue></Attribute></AttributeStatement>
as specified in the documentation. The question is, how to get the true values that azure active directory is sent to me and not these encoded values, I am using Python 3 and Google App Engine, in addition to mentioning azure active directory and saml 2.0 to do the login process, I leave the SAML response complete in this url in case it serves to give a better context to my question.
As mentioned above, the SAML response you are getting is encrypted. Specifically Azure is encrypting its assertions (including the ones you are looking for) inside an encrypted body called CipherData.
You have two options:
1 - Disable SAML response encryption.
Azure AD calls SAML response encryption as SAML token encryption which is a bit confusing. You can follow this guide to disable the response. You must have uploaded an encryption public key/cert before.
2 - Configure your service provider to supported encrypted SAML responses.
The SAML token is encrypted.
You need to get the client side certificate used for this and use that to decrypt it.
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).
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!
Using WSO2 5.1.0. Needs to send SAML assertion like firstName, lastName from WSO2 as IDP to SP. Refer Configuration. User profile do have first name and last name values.
Restarted WSO2, no error in logs. But I don't receive these values in SAML response sent from WSO2 to my Service porvider.
For this, in your Service Provider's SAML Configuration, you need to make sure following two checkboxes are selected.
Enable Attribute Profile
Include Attributes in the Response Always
Then, inside the Claim Configuration section of the Service Provider configuration, you need to add the particular claims you need to receive as Requested Claims. Then these claims will be included in SAML response.
If you want the claims to have a different key name, you can define a custom claim dialect there and provide your own key names for claims.
We are considering to send some session information in the SAML claims.
The session information would be something to received by the chosen (custom) authenticator, such as value of an HTTP header (X509 DN), extra information provided on the logon screen, etc ...
Currently (by default) all claims are read from the userstore (as mapped by the claim mapping).
The only way I currently found to pass the session information is to implement/overwrite the SAML2SSOManager implementation.
Is there any simpler way to pass some user attributes from the authenticator which will be handled as a claim by the default SAML2SSOManager implementation?
I see the federated authenticators use context.getSubject().getUserProperties() to pass remote claims to the SAML response. Is it a way? ( regardless I put any ClaimMapping into the userProperties and declare the claim as required, I am unable to get it out as SAML response claim)
Thank you in advance
Apparently the way to go is implementing a custom ClaimHandler as described http://pushpalankajaya.blogspot.be/2014/07/adding-custom-claims-to-saml-response.html
The local authenticator can set the claims as user properties (of the subject).
In this case extending the handleLocalClaims should be enough, not to mess with federated mapping (where federated authenticators use the subject userAttributes as well)