Page Comparison

...

In a SP-initiated authentication flow, the end user types browser sends an authentication request to the SP URL and the browser redirects to the IdP. When this flow is utilized to perform SSO login from ASM, Apica sends the request via the browser login URL (in this case, ASM/ALT is the SP).  The SP responds to the browser with a redirect to the IdP for authentication and the RelayState is sent as a token/value without being inspected or modified. Then, with a SAML request that includes a RelayState token/value.  When the browser sends the request to the IdP (e.g. Okta, Centrify, Azure AD., etc.) is responsible for responding to the authentication request and authorizing access to the portal.

This is important because the IdP can serve more than one SP; after the request is sent, the IdP knows Apica is initiating the SAML authentication flow and Apica does not need to modify the URL to identify itself to the IdP.

In an IdP-initiated authentication flow, the end user types the IdP URL into a browser, which acts as a User-Agent; therefore, the IdP does not know who is sending the SAMLRequest. When this flow is utilized to perform SSO login from ASM, the end user must authenticate to the IdP and attempt to access the ASM portal via the IdP. A , the IdP authenticates the user and responds with a browser redirect that includes a SAML message with a SAML assertion and the unmodified RelayState.  When the browser sends the SAML response with the unmodified RelayState to the SP, the SP uses the RelayState to validate the that the assertion is the result of a request originating from the SP.Once SSO configuration is complete in ASM/ALT, SP-initiated authentication is supported by default.  Although it is generally accepted that IdP-initiated authentication is less secure because the SP is unaware of an authentication request when it receives the SAML message/assertion and therefore cannot detect if the message/assertion was stolen or replayed, IdP-initiated authentication can be supported with appropriate configuration on the IdP.

In an IdP-initiated authentication flow, the end user navigates to the IdP URL, is prompted for authentication and is presented with a link to the SP (in this case, ASM/ALT is the SP).  A set of predetermined additional attributes associated with the authenticated user and the SP will be populated in the SAML response which is POSTed back to Apica. This login flow uses RelayState to signal to Apica what URL Apica should POST/redirect to after successful sign-on. The SAML 2.0 Standard states that RelayState "MAY be the URL of a resource at the service provider.” So, in this IdP-initiated SSO case, the RelayState field in the SAML post from the browser is empty/absent but is used by the IdP for the URL redirect for the POST for Apicasent to the browser (customerName (required), RelayState (optional?), etc.), with a redirect to the SP.  The browser then POSTs the SAML message/assertion to the SP.  For Apica, this login flow can include RelayState to indicate what URL Apica should redirect to after a successful SAML assertion.

When this flow is utilized, the end user logs into their IdP (e.g. Okta, Centrify, Azure AD., etc.) and clicks on a link to ASM from there. Then, the IdP sends the browser a customerName and RelayState attribute in the SAML response, which will redirect the user to the ASM dashboard.

...