I am using Spring SAML integration. I am getting below error when I tried to SAML logout without SingleLogout point.
I override the SAML method to check metadata has any SingleLogout point or not but it's not working.
Caused by: org.opensaml.saml2.metadata.provider.MetadataProviderException: IDP doesn't contain any SingleLogout endpoints
at org.springframework.security.saml.util.SAMLUtil.getLogoutBinding(SAMLUtil.java:108)
at org.springframework.security.saml.websso.SingleLogoutProfileImpl.sendLogoutRequest(SingleLogoutProfileImpl.java:66)
at org.springframework.security.saml.SAMLLogoutFilter.processLogout(SAMLLogoutFilter.java:140)
To properly override the lack of single logout endpoint in the metadata, you'd have to provide your own implementation of org.springframework.security.saml.websso.SingleLogoutProfile and inject it as a dependency in your application config. Certainly doable but quite a bit of effort for a problem that has a simpler solution: manually modify the metadata you received from the IdP and add the endpoint. (If the metadata is signed, you'll need to remove the signature).
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 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.
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.
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.