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.
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.
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.
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 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!
I am implementing single sign on with multiple SPs. Here is my basic understanding:
1) Browser(User) requests resource from Service Provider (SP).
2) SP Redirects (with SAML Request) to Identity Provider (IdP).
3) Since it is first login, User gives the (IdP) his/her valid credentials.
4) IdP then redirects Browser (with SAML Response which includes SAML token) to the SP page.
Now let's say I have Service Provider A and Service Provider B. A user has completed the step about for Service Provider A. From service provider A (salesforce.com in my scenario), I have written a server-side method which instantiates a callout to an endpoint on Service Provider B. Is it possible to re-use the SAML assertion in this case? I.e. will service provider B trust the backend method?
You would have to customize Service Provider B in order for it to accept, understand and interpret the Assertion obtained by Service Provider A. It would certainly not work out-of-the-box.
The SAML Assertion included in the SAML Response to Service Provider A contains pieces of data which correlate it with the original SAML Request and define recipients of the message (for example using elements SubjectConfirmationData and Audience). The Service Provider B would need to ignore values in these fields, as it is actually not the indented recipient of the Assertion.
The problem of how to broker trust between two machines where user's identity is asserted by an identity provider can be solved with multiple standard approaches. One is to use a Session Token Service (based on WS-Trust) which defines how to request and issue tokens to 3rd party services. Another is to use OAuth 2.0. You could of course also simply authenticate Service Provider A to Service Provider B using a custom scheme with a password, HMAC, ...
The short answer - no if Service Provider B is implemented as a standard SAML 2.0 SP.
SAML 2.0 assertions are "targeted" and signed. They have a specified audience and a recipient URL. You cannot change them without breaking the signature.
The assertion received by SP A contains the name of SP A as audience and the ACS end point of SP A as recipient URL. Such an assertion will not be accepted by SP B.
What prevents you from just calling SP B in a standard way and let it initiate its own SAML 2.0 flow? Another option would be to perform an IDP-initiated SSO flow for SP B. Not all IDP implementations support it though.