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.
Related
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 working on a SPA application, and I'm using the recommended implicit flow and I'm able to get access_token and id_token. As I need more than the profile info, I've created a separate endpoint to return the user profile information (along with all the other information that's specific to our business) and this endpoint is protected, and can be accessed only with an access_token as the bearer token. Right after getting access_token in SPA, I call this endpoint to get all the user information (which includes first name, last name etc., that gets displayed on the UI). If there is any problem with the returned id_token and access_token pair, the user profile info endpoint call would fail. So, do I really need to validate the id_token? as I'm not relying on any information within that token.
For authenticating against external login provider or authorization code flow, validating the id_token makes sense, but in my case I'm not sure about it.
According to OpenID spec:
When using the Implicit Flow, the contents of the ID Token MUST be validated in the same manner as for the Authorization Code Flow, as defined in Section 3.1.3.7, with the exception of the differences specified in this section.
1. The Client MUST validate the signature of the ID Token according to JWS [JWS] using the algorithm specified in the alg Header Parameter of the JOSE Header.
2. The value of the nonce Claim MUST be checked to verify that it is the same value as the one that was sent in the Authentication Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is Client specific.
Why don't you utilise response_type parameter in authorisation request. By changing its value, you can alter what you receive for authorisation response.
Identity documentation mention about possible response type values. Following is an extraction from their documentation,
As you can see, if you do not want SPA to receive the id token, you can set the response_type value to token. If you do so you will only get an access token, which is enforced by OAuth 2.0 specification. (See the OAuth 2.0's implicit flow response_type explanation from here). Note that when you use response_type=token , you are using OAuth 2.0 (not OIDC)
I don't see any wrong in your approach as long as you utilise features enabled by respective protocols.
Kentor - Using the SampleMvcApplication with success through their StubIdp but when I try with Clareity I receive the above error.
Without knowing anything about the implementations ( Kentor, SampleMvcApplication, StubIdP, Clareity )it looks as if:
Your Identity Provider implementation does not return a 'RelayState' parameter in the body of the HTTP POST along with the SAMLResponse.
Your Identity Provider implementation has added an InResponseTo attribute in the SAMLResponse element
Your Service Provider implementation interprets this as an IdP initiated SSO since it does not see a 'RelayState' parameter
Your Service Provider throws an error since it doesn't make sense for an SAMLResponse in an IdP initiated SSO flow to have an InResponseTo. InResponseTo refers to an AuthenticationRequest which is only there in a normal SP initiated SSO.
To get more help, you should tell us a little about the implementation you are using and your configuration.
I need a clarification about the terminology used in SAML2.0. I want to know if by "assertions" we mean a particular subcategory of SAML2.0 messages
or if we mean ALL SAML2.0 messages.
A SAML Assertion is an XML document that represents a set of claims (i.e. name/value pairs) about a user asserted by an Identity Provider. A SAML Assertion is not a SAML message itself, but it is contained in a SAML Response message. Apart from that there are other SAML messages such as SAML Requests, Logout Requests and Logout Responses that don't contain Assertions.
SAML assertion is generated at the IDP(PF). It is consumed at the SP(PF). Is saml assertion tampering possible? If so, how to test it? I am trying to track get & post requests.
When I post the generated SAML Response to https://machine_name:port_no/sp/ACS.saml2, I get 404 error. I understand that we cannot hit the url.when I give the destination resource url, the resource page is opened.But I don't find the response in my server log.
I want to post the generated response with slight modifications and test if it throws any error. The intruder shouldn't be allowed to get the resource. Though I modify the response, I am able to hit the url & access the page.I am using POSTMAN chrome extension for this purpose.
Note : I am extracting saml response from the Agentless Integration Kit sample application.so the destination url is https://machine_name:port_no/AgentlessIntegrationKitSampleSP
Thanks,
Aswini J
If you want to tamper with the SAML data in the browser, you should use the Tamper Data extension for Firefox. It will allow you to step through each transaction and selectively modify the data.
However, you cannot successfully tamper with the SAML Response because it is a digitally signed (and optionally encrypted) message. Any tampering of the signed data will invalidate the message and PingFederate will not allow the message to go through. This is mandated per the SAML XMLDig specification which PF strictly enforces.
The info exchanged between the PingFederate (SP) and QuickStartApp (SP) is not SAML -- it is a "one time use" reference token that refers to information that is stored in PingFederate runtime memory. If you modify this value, PF will throw an error because it will not reference any known data.