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.
Related
I want to know if there is a way to only use GET type requests in the exchanges with the IDP. I don't want to use a POST method to exchange with the IDP. Is there a parameter that allows this ?
Take a look at section two of the "Conformance Requirements for the OASIS Security Assertion Markup Language (SAML) V2.0" specification.
The SAML authn request sent to the IdP may be sent using HTTP-Redirect, HTTP-Post or HTTP-Artifact. The SAML response sent to the SP may be sent using using HTTP-Post or HTTP-Artifact. HTTP-Artifact is rarely used which means the IdP will send the SAML response using HTTP-Post.
There isn't an option to send the SAML response using an HTTP GET. The reason for this is that SAML responses are generally too long to be encoded as query string parameters.
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.
Is it possible to configure a Relying Party in ADFS to send the SAML Response to a Destination URL while having the Recipient URL in the SubjectConfirmationData block be a different URL? I haven't seen anyway to configure those two to be different in the ADFS UI. Our use case is that we have a proxy we want to send the SAML Response through en-route to the service provider (us in this case) which is expecting the Recipient URL to be a certain value. We obviously can't manipulate that value in the SAML Response using the proxy itself since those responses are signed from the IDP.
I checked and there is no available way to configure the relying party in ADFS in the above way you have mentioned. URL must match the one that you specify in the Service provider ID field of the web server IDP configuration document.
I am trying to understand implementation of SSO system for service provider. Here are my questions.
User logs into System A. System A does authentication and displays a link to the user on page. When User clicks the link, System A redirects user to System B where System B is a 3rd party vendor. Who is IdP here and who is SP?
Is there any server to server communication in a flow initiated from IdP to SP? Is it required in all scenarios?
can you explain the data flow step by step in case of IdP initiated flow to SP?
Any material on this same or simple explanation will help.
In answer to your questions and assuming SSO via Security Markup Language (SAML):
System A is the Identity Provider (IdP) and System B is the Service Provider (SP).
There is no server-to-server communication. Information is passed via the client browser using HTTP bindings, for example HTTP POST.
Step by step IdP-initiated workflow (taken from OASIS SAML V2.0 Technical Overview):
If the user does not have a valid local security context at the IdP, at some point the user will be challenged to supply their credentials to the IdP site, idp.example.org.
The user provides valid credentials and a local logon security context is created for the user at the IdP.
The user selects a menu option or link on the IdP to request access to an SP web site, sp.example.com. This causes the IdP's Single Sign-On Service to be called.
The Single Sign-On Service builds a SAML assertion representing the user's logon security context. Since a POST binding is going to be used, the assertion is digitally signed before it is placed within a SAML message. The message is then placed within an HTML FORM as a hidden form control named SAMLResponse. (If the convention for identifying a specific application resource at the SP is supported at the IdP and SP, the resource URL at the SP is also encoded into the form using a hidden form control named RelayState.) The Single Sign-On Service sends the HTML form back to the browser in the HTTP response. For ease-of-use purposes, the HTML FORM typically will contain script code that will automatically post the form to the destination site.
The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the SP's Assertion Consumer Service. The service provider's Assertion Consumer Service obtains the message from the HTML FORM for processing. The digital signature on the SAML assertion must first be validated and then the assertion contents are processed in order to create a local logon security context for the user at the SP. Once this completes, the SP retrieves the RelayState data (if any) to determine the desired application resource URL and sends an HTTP redirect response to the browser directing it to access the requested resource (not shown).
An access check is made to establish whether the user has the correct authorization to access the resource. If the access check passes, the resource is then returned to the browser.