As a service provider, when we receive the HTTP Redirect logout request from an IdP, documentation states that we should do the following:
Validate the logout request > Invalidate the user session > Send a logout response back to the identity provider.
Which endpoint do we redirect the logout response back to? I would have thought it would be a part of the logout request but it isn't. Is it just the IdP Single Logout URL?
Typically the IDPSSODescriptor of the IdP meta data defines the SingleLogoutService for each supported protocol binding.
E.g. Excerpt from IdP meta data from SSOCicrle)
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://idp.ssocircle.com:443/sso/IDPSloRedirect/metaAlias/publicidp" ResponseLocation="https://idp.ssocircle.com:443/sso/IDPSloRedirect/metaAlias/publicidp"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://idp.ssocircle.com:443/sso/IDPSloPost/metaAlias/publicidp" ResponseLocation="https://idp.ssocircle.com:443/sso/IDPSloPost/metaAlias/publicidp"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://idp.ssocircle.com:443/sso/IDPSloSoap/metaAlias/publicidp"/>
If you did not receive IdP meta data you need to reach out to the IdP admin and request that information.
Note: It depends on the SP implementation which binding is used to send the LogoutResponse. Some use the same binding which was used by the IdP to send the LogoutRequest, some use the first binding defined in the IdP meta data and some use a specified binding.
Related
I am implementing SSO using an external Identity provider to which I do not have access yet.
The IDP metadata IDPSSODescriptor has one SingleSignOnService tag with a binding value of: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
Does this imply that I cannot initiate an authentication request to the SingleSignOnService location with a GET request or that the service will respond with a POST request?
It means that the protocol endpoints that you will interact with expect POST interaction from the client (typically a browser). This is required these days for sending the assertion from the IdP to SP, but Redirect is usually acceptable in the case of the SP sending an AuthnRequest to the IdP.
In SAML, if the SP sends a RelayState parameter during an SP-initiated SSO login, the IdP (OneLogin) should send the RelayState back exactly as the SP sent it. This can be used to navigate to a particular page, etc.
However, OneLogin doesn't seem to be sending it back. When configuring a OneLogin app, the configuration has a field called RelayState. I've never needed it before now so I've left that empty thinking it's is the 'default' RelayState in case the SP doesn't send one or in case its a IdP initiated login but this doesn't seem to be the case.
Is there a way to get OneLogin to send back the RelayState the SP sent during an SP-initiated login? Do I need to add some variable/tag in this RelayState app configuration field? As an aside, even if I put something random in the RelayState field OneLogin is not getting sent to the SP even on an IdP initiated login (so maybe I need to turn it on somewhere I'm not seeing).
I tested here using our SP application and OneLogin without any issues. The relay state included with the SAML authn request was returned by OneLogin with the SAML response.
My understanding is that the relay state that can be configured in OneLogin is for IdP-initiated SSO only. I've left this blank. There was no special setting required in OneLogin to get it to correctly return the relay state as part of SP-initiated SSO.
Are you sending the authn request using HTTP-Redirect or HTTP-Post?
Either should work. I suggest double checking the RelayState parameter is included correctly with the authn request.
I have a saml Keycloak client which contains an Authentication Flow Override to a custom keycloak SPI authenticator built in java and deployed in the keycloak env. The authenticator is pretty simple, it displays a username field and takes that username, does a 3rd party check, then returns a verdict (go/nogo, yes/no, etc.)
I have a SAML SP sending a request to this keycloak client (as an IDP). The SP request has a LoginHint. When the Custom Authenticator receives this request in the authenticate method, it cannot retrieve the HTTP Post parameters because there are none.
When user enters their information into the custom authenticators form and clicks submit, and when the action method takes over, the new HTTP POST params are there.
I need to retrieve the loginHint in the authenticate method from the incoming SP SAML request.
anyone know how to do this? i cant read in the login_hint for the life of me.
login_hint and variations thereof belong to OpenID Connect (OIDC) implementations. In SAML you have to use RelayState (recommended) or an authentication request extension.
During SP-initiated SSO, the Authentication Request(AuthnRequest) can specify to which Assertion Consumer Service (ACS) the Security Assertion Markup Language(SAML) Response has to be sent in the AssertionConsumerURL.
Similarly in IDP initiated SSLO where should we send the SamlLogoutResponse to ?
In the logout request example I dont see AssertionConsumerURL. Do we have to send the response to what is specified in the destination parameter?
ACS and SLO (Single Logout) are different endpoints in SAML.
They are normally specified in the metadata.
Method 1
Browser is directed to Service provider. Service provider checks whether there is any cookie set, If no then it redirects browser to Identity provider and Identity provider(IdP) validates user and redirect a ID to Service Provider(SP). SP takes that ID and set it as session cookie in browser and redirects user to service. Next time, if user asks for service again in same session the SP checks for cookie and redirects directly to service.
Method 2
Browser is directed to Service provider. Service provider redirects to IdP. IdP checks for its cookie and if cookie is not present,IdP authenticates user and set session cookie in browser. Redirects positive response to SP. SP redirects user to service. Next time user asks for the service within the session, Browser is directed to Service provider. Service provider redirects to IdP.IdP checks for its cookie and if it is present,it sends positive response to SP.
I am pretty sure that Guanxi implementation of Shibboleth (SAML2 profile) and almost sure that Shibboleth itself can be simplified to your "method 1".
You better check some of existing SAML2 profile implementations.
I don't believe either of those are valid SAML implementations. Usually in SAML identity information is communicated in a HTTP POST or through SOAP web service (see: http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language#SAML_2.0_bindings). Cookies are not used to 'authenticate' a user.
We have a web application that uses SAML 2.0 XML communicated in a HTTP POST to authenticate the user. Our customer's employees go through the identity provider on their side of the firewall to access our application.