Does AzureAD support SessionNotOnOrAfter attribute of "AuthnStatement" section in SAML response?
If not, can we consider NotBefore and NotOnOrAfter attributes of "Conditions" section as valid session time window (session length)?
Yes, The NotBefore and NotOnOrAfter attributes specify the interval during which the assertion is valid.
<Conditions NotBefore="2013-03-18T07:38:15.128Z" NotOnOrAfter="2013-03-18T08:48:15.128Z">
<AudienceRestriction>
<Audience>https://www.contoso.com</Audience>
</AudienceRestriction>
</Conditions>
The value of the NotBefore attribute is equal to or slightly (less than a second) later than the value of IssueInstant attribute of the Assertion element. Azure AD does not account for any time difference between itself and the cloud service (service provider), and does not add any buffer to this time.
The value of the NotOnOrAfter attribute is 70 minutes later than the value of the NotBefore attribute.
Reference: Single Sign-On SAML protocol
As of today, AzureAD does not support SessionNotOnOrAfter attribute and does not allow to configure session lifetimes derived from the SAML Response. The "NotOnOrAfter" attribute should not be used to control session lifetime, because it has totally different meaning and purpose. See NotOnOrAfter in SubjectConfirmationData and Conditions and SessionNotOnOrAfter.
Related
Reading the SAML core documentation I can't figure out where InResponseTo is required (if anywhere) in an SP-initiated SAML2.0 Post Redirect flow.
The docs stipulate that InResponseTo is optional in the SubjectConfirmationData. The documentation is quiet on whether or not InResponseTo should be part of the Response tag, although my experience is that in practice it's almost always present (I suspect the InResponseTo's existence in the Response is covered by other SAML documentation that I haven't been able to find). Can the IdP decide freely if the InResponseTo value goes in the Response tag or in the SubjectConfirmationData (or even somewhere else)?
(For the avoidance of doubt, I understand InResponseTo is not part of the SAMLResponse in an IdP-initiated response.)
There is clear documentation available for InResponseTo in the SAML core documentation under Section 3.2.2 Complex Type StatusResponseType.
The <Response> message element has the complex type ResponseType, which extends StatusResponseType. Check Section 3.3.3
InResponseTo [Optional] A reference to the identifier of the request
to which the response corresponds, if any. If the response is not
generated in response to a request, or if the ID attribute value of a
request cannot be determined (for example, the request is malformed),
then this attribute MUST NOT be present. Otherwise, it MUST be present
and its value MUST match the value of the corresponding request's ID
attribute.
It is optional in the Response message because SAML allows for the IdP to send a unsolicited response to the SP without the SP requesting it. Under 3.2.1 for the AuthnRequest it states that InResponseTo must match ID in the AuthnRequest.
More importantly. When you use requests and response for Web Browser SSO, you are using the Web Browser SSO Profile in the SAML Profiles spec.
The profile adds extra requirements on how the requests and responses are used.
4.1.4.2 <Response> Usage states
If the containing message is in response to an ,
then the InResponseTo attribute MUST match the request's ID.
4.1.4.3 <Response> Message Processing Rules states
Verify that the InResponseTo attribute in the bearer equals the ID
of its original message, unless the response is unsolicited (see Section 4.1.5 ), in
which case the attribute MUST NOT be present
The SAML Profile spec adds alot of important requirements for the context of usage of the protocol messages in the core spec and is very important for interoperability and security.
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'm trying to use the same salesforce app with multiple SAML service providers. All of the service providers have the same identifiers, the only things that I need from sales force is to send the SAMLResponses to Assertion Consumer Service(ACS) that I specify when I construct the authNresponse request.
When I construct the SP initiated an authentication request to SF I include the ACS URL(as AssertionConsumerServiceURL field) in the SAMLRequest token, but it doesn't seem to override the ACS URL that is mandatory in the connected apps SAML settings.
Maybe there is a way to override the ACS URL?
Not sure about SalesForce but in general, yes we can. Just add the AssertionConsumerServiceURL="xxx" tag to the AuthNRequest. I just tried this myself (with Optimal IdM). Unless SalesForce has restrictions in place that don't accept overriding, this is possible.
So a sample AuthNRequest would look like:
<samlp:AuthnRequest Version="2.0" IssueInstant="2018-06-29T14:46:11.33Z" ForceAuthn="false" IsPassive="false" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="xxxxxxx">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">xxxxxxx</saml:Issuer>
</samlp:AuthnRequest>
PS: I know it's an old thread, but answering anyway for the sake of others.
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)