SP- and IdP-Initiated Logins

The SP-Initiated login is the most common flow. It starts when a user goes to an IDC application (Service Provider) and that application redirects the user to the IdP for authentication.

• User visits one of the IDC tools (for example http://idc.com) and clicks “Login” (or is automatically redirected because their company is SSO-enabled). They might first see a page or a URL that includes /saml-welcome/CompanyCode which triggers the SAML request.
• IDC (the SP) sends a SAML Authentication Request to your IdP’s SSO URL (which IDC knows from your metadata). This is usually done via an HTTP Redirect binding by the user’s browser or sometimes HTTP POST.
• The user’s browser is sent to your IdP (like ADFS or Okta), along with the SAML request (which contains IDC’s details and a unique request ID).
• The IdP (if not already logged in via SSO session) will prompt the user for credentials. The user logs in with corporate username/password or whatever method you use.
• The IdP then builds a SAML Response containing the assertion with user attributes, and sends that back to IDC’s ACS (Assertion Consumer Service) URL via the user’s browser (usually using an HTTP POST to IDC’s ACS endpoint).
• IDC receives the SAML Response, verifies the signature, and if all good, logs the user in, establishing an application session for them.
• The user is now on IDC’s site, authenticated. If it’s the first time, an IDC account might be created on the fly (using the attributes provided to populate name/email).

From your perspective, SP-initiated is straightforward because IDC handles redirecting users to the right place (you just need to ensure the SAML integration is set up). Typically, IDC will provide that saml-welcome link for testing, but in production, they might also integrate with their login page detection (e.g., if user selects your company name, etc.). IDC will offer a unique URL for your company’s users to bookmark that will point to your SSO integration right away.

This flow starts from your IdP side without an explicit request from IDC. For instance, a user logs into your corporate portal and clicks an “IDC” icon or link which then triggers a SAML Response to IDC.

• On your IdP, you configure an “application” or “relying party” that users can initiate. In ADFS, that might be through an IdP Initiated Sign-On page or a special relay state. In Okta/AzureAD, it might be a tile in the user’s app dashboard.
• When the user triggers it, the IdP immediately sends a SAML Response to IDC’s ACS URL with the user already authenticated (this is often called an unsolicited SAML response).
• IDC receives it just like in SP-initiated flow and logs the user in.

IDC supports IdP-initiated logins as well. There’s no technical difference in the assertion requirements. The main difference is there was no “request” from IDC. IDC doesn’t mind – as long as the response is valid, IDC will log the user in.

One thing to consider is RelayState. In SAML, a RelayState parameter can be used to direct the user to a specific page after login. In SP-initiated flows, IDC might set a RelayState to remember where the user was trying to go. In IdP-initiated, some IdPs allow you to set a default RelayState (like a deep link). The IDC documentation references some IdP-specific notes (e.g., Shibboleth and ADFS IdP-initiated RelayState support). If you need users to land on a particular IDC page post-login, coordinate with IDC on what RelayState URL or value to use.

SP-initiated is generally simpler for users (they just go to IDC’s site and get redirected). IdP-initiated is useful if you have a central launcher/dashboard. Most organizations enable both. IDC mentions they provide an easy way for SP-initiated and that IdP-initiated isn’t strictly needed, but it’s available.

• For SP-initiated, use the URL given by IDC for test (e.g., …/saml-welcome/[code] as mentioned). This will immediately send you to your IdP. If something is wrong (like IDC not configured, or NameID missing), you might get bounced back to an error page or to the login.
• For IdP-initiated, try triggering from your IdP’s side. In ADFS, a quick way is using its IdP Initiated Sign-On page (often at https:///adfs/ls/IdpInitiatedSignOn.aspx). Enable it if not enabled (it’s disabled by default in new ADFS but can be turned on via Set-ADFSProperties). There you can choose the relying party (IDC) and initiate login. Or craft a form to post to IDC’s ACS with an encoded SAML (not usually done manually).
• Alternatively, IDC might provide a direct link for IdP-init as well, but typically it’s IdP that starts it.