SSO Logout Behavior

Logout in a federated SSO scenario can be tricky, because the user potentially has active sessions both on the Service Provider (IDC) and on the Identity Provider (your system). IDC’s support for SAML Single Logout (SLO) is limited and not fully compliant with the SAML 2.0 standard. Here’s what you need to know.

Default – Local Logout

By default, when a user logs out of an IDC application, IDC will perform a local logout only. This means IDC ends the user’s session in the IDC app, but it does not notify the IdP or other apps. The user is essentially logged out of IDC, but they may still have an active login session at your IdP (and possibly other SPs). After local logout, the user could still be considered “logged in” elsewhere, and if they return to IDC and initiate SSO again, they might get silently logged back in (since IdP still has a session for them).

Why not full Single Logout (SLO)?

True SAML Single Logout involves the SP sending a LogoutRequest to the IdP, the IdP in turn logging the user out and sending LogoutResponses, and possibly coordinating logout with other SPs. IDC’s current SAML implementation does not fully support this sequence as defined in the spec. Specifically:

  • IDC’s SP can initiate a logout by sending a SAML LogoutRequest to the IdP (if configured to do so). So, when a user clicks logout on IDC, it could send a request to your IdP’s SLO endpoint.
  • However, IDC’s SP is not able to handle the LogoutResponse from the IdP. In a proper SLO, the IdP would reply to IDC’s request with a LogoutResponse to confirm, but IDC doesn’t process it. This means after IDC sends the logout request, from IDC’s perspective it’s done – it won’t wait for or act on a response.
  • IDC’s SP also cannot accept a LogoutRequest coming from the IdP. If, say, the user triggered logout from another application and the IdP tries to log everyone (including IDC) out by sending a request to IDC, IDC will not handle that. In essence, IDC won’t be a participant in a global logout initiated elsewhere.
  • Because of the above, IDC does not include a SingleLogoutService endpoint in its metadata (since it can’t fully support the protocol). Some IdPs (like Azure AD) require an SP to have an SLO endpoint to even configure logout, which complicates things.

The Impact

The practical effect is that when a user logs out of IDC:

  • The user will be logged out of IDC’s session immediately.
  • If IDC tries the limited SLO (LogoutRequest), your IdP might receive it and log the user out on the IdP side. But IDC won’t handle the response.
  • If your IdP is Azure AD, note Azure AD supports only redirect binding for SLO, while IDC only does (if at all) POST binding. That means Azure AD cannot process IDC’s logout (since IDC would send a POST LogoutRequest, Azure only listens on Redirect). Azure AD therefore is incompatible with IDC’s SLO implementation. However, Azure AD SSO login still works fine – just SLO doesn’t.
  • If your IdP is ADFS or others that might accept a POST logout, they might log the user out. But since IDC won’t process responses, it’s a one-way communication.

Alternative Logout Solution

Recognizing the limitations, IDC offers a workaround approach for those who want a better logout experience:

  • IDC can be configured to redirect the user to a specified URL (provided by you) after the user logs out of IDC. This URL would typically be one on your own domain.
  • When the user is redirected to that URL (let’s call it the post-logout URL for your IdP), it’s up to your application/IdP to then identify the user (maybe via an existing IdP session cookie) and log them out from the IdP side.
  • Essentially, IDC says “I’ve logged the user out here, now I’m sending them to you”, and you do any cleanup needed to fully log them out.
  • For example, if using ADFS or a custom IdP, you could have that URL be something that triggers the IdP’s logout. Perhaps a page that calls the ADFS /adfs/ls/?wa=wsignout1.0 (in WS-Fed terms) or similar. Or if using a cloud IdP, maybe just a landing page with instructions or a script to clear session.

This is not a standardized SAML SLO, but it achieves the goal: the user ends up at your site where you can say “You have been logged out of IDC. Click here to log out of all services.” or automatically initiate IdP logout.

To use this alternative, coordinate with IDC to set the logout redirect URL for your SSO config.

Summary of the Logout Options

  • Do nothing special (default): User clicks logout on IDC, IDC ends its session, user is still potentially logged into IdP. If they come back, SSO might auto-login them. They’d have to close their browser or explicitly log out of IdP via some other means to fully end the session.
  • Limited SLO (not reliable): IDC can send LogoutRequest, works for some IdPs but not all, and IDC won’t confirm. Possibly logs user out of IdP if IdP doesn’t require response.
  • Custom Redirect on Logout (recommended if IdP logout needed): After IDC logout, user is redirected to your provided URL, where you handle IdP logout. This works consistently as long as you implement that page on your side. It is simpler than true SAML SLO and avoids compatibility problems.

Most IDC customers opt to simply accept that logging out of IDC doesn’t log you out of corporate SSO (similar to how logging out of one SSO app often doesn’t log you out of everything unless there is a full centralized logout). Given user expectations, it’s usually fine – if they close the browser, session cookies at IdP will eventually expire or be out of scope. However, if security policy demands a thorough logout, use the redirect approach.

Important note – if you want to enable any kind of SLO or logout redirect, you must explicitly ask IDC to enable it and provide necessary info (like the URL). By default, IDC does not enable Single Logout – it’s only turned on if requested, to avoid interfering with simpler setups.

To conclude: IDC’s SAML SSO gets users logged in seamlessly, but for logout, plan for the limitations. Either accept that users need to log out of IdP separately (if at all), or implement the post-logout redirect solution. And note that some IdPs like Azure AD can’t do SAML logout with IDC due to binding mismatch – in such cases the redirect solution is the only way to attempt a unified logout experience.

Need Help Getting Started?

For any technical issues or questions, you can reach out to IDC’s support team via

  • Email at idc_support@idc.com (preferred)
  • Phone +1 508-935-4323. If no one will be available to pick up the phone leave a message and it will be directed to the support team who will get back to you.