Differences between Initiated SSO SPs and Initiated SSO IDPs

Question

Can someone explain to me what are the main differences between SSO-initiated SPOs and SSO - initiated IDPs , including, what would be the best solution to implement a single sign in conjunction with ADFS + OpenAM?

Answer 1

In the IDO Init SSO (Unsolicited Web SSO), the federation process is initiated by the IDP sending an unsolicited SAML response to the SP. In the SP-Init, the SP generates an AuthnRequest, which is sent by the IDP as the first step in the federation process, and the IDP then responds with a SAML response. IMHO ADFSv2 support for SAML2.0 Web SSO SP-Init is stronger than IDP-Init support: integration with third-party Fed products (mainly RelayState support), so if you have a choice, you will want to use SP-Init, as it will make life easier with ADFSv2.

Here are some simple single sign-on descriptions from the PingFederate 8.0 Getting Started Guide that you can follow, which may also help - https://documentation.pingidentity.com/pingfederate/pf80/index.shtml#gettingStartedGuide/task/idpInitiatedSsoPOST.html

Answer 2

IDP Initiated SSO

From the PingFederate documentation: - https://docs.pingidentity.com/bundle/pf_sm_supportedStandards_pf82/page/task/idpInitiatedSsoPOST.html

In this case, the user logs into IdP and tries to access the resource on the remote SP server. The SAML statement is carried to the SP through the HTTP POST.

Processing steps:

• The user has logged into IdP.
• The user is requesting access to a secure SP resource. User has not visited SP site.
• If desired, IdP retrieves attributes from the user data store.
• IdPs Single Sign-On returns an HTML form to the browser with a SAML response containing an authentication statement and any additional attributes. The browser automatically submits the HTML form back to SP.

SP Initiated SSO

From the PingFederate documentation: - http://documentation.pingidentity.com/display/PF610/SP-Initiated+SSO--POST-POST

In this case, the user tries to access the protected resource directly on the SP website without logging in. The user does not have an account on the SP site, but has a federated account managed by a third-party IdP. The SP sends an authentication request to IdP. Both the request and the returned SAML statement are sent through the users browser through HTTP POST.

Processing steps:

• The user is requesting access to a secure SP resource. The request is redirected to the federation server for authentication.
• The federation server sends the HTML form back to the browser with a SAML request for authentication from IdP. The HTML form is automatically submitted to IdPs Single Sign-On.
• If the user has not logged in to the IdP site yet or re-authentication is required, IdP asks for credentials (for example, ID and password) and the user logs in.

• Additional user information can be obtained from the user data store for inclusion in the SAML response. (These attributes are predefined as part of the federation agreement between IdP and SP)

• IdPs Single Sign-On returns an HTML form to the browser with a SAML response containing an authentication statement and any additional attributes. The browser automatically submits the HTML form back to SP. NOTE. SAML specifications require POST responses to be digitally signed.

• (Not shown) If the signature and approval are valid, SP establishes a session for the user and redirects the browser to the target resource.

Answer 3

SP Initiated SSO

SP: "Hey, do you know Sala?"

IdP: "I? ... Oh, that's right! Yes, I know Sal"

SP: "Oh, cool, I'll let her in."

IdP Initiated SSO

IdP: "Hi, Sal says you know her."

SP: "I know? .. Oh, yes, I will give it."