2

I work on a software product that allows customers to use SAML or OAuth provisioning to their users. e.g to Azure AD.

Now non technical savvy users understandably presume that logging off from our software (the SP) would log them out. Because the SSO session still exists from the IDP it doesn't.

Their argument is that using a shared workstation and logging out leaves them exposed and without understanding that they need to sign out of their IDP on their workstation puts them at risk.

I'm of the understanding that this is a poor user experience due to the presumption logging out would log you out. Some SAML providers etc. facilitate a SP initiated single sign off from the IDP, but others don't.

Should I have a secondary "Log off from Idp" button that either triggers SP initiated log off or redirects to the IDP logout page to provide a better user experience? How would they know the difference and what this means?

Unsure what the best convention is around this that will help non tech savvy users as much as possible against leaving IDP accounts open on shared workstations. Or assist in explaining how SSO works as a SP.

Many companies use a SAML provider for their internal works and their customers, but often their customers only use that connection for a single SP and don't understand they are using a provider such as SAML. Our software facilitates for both internal staff users (who wouldn't want single sign off) and also external users in the same system who may or may not need the benefits of SSO.

I understand shared responsibility should mean the customers shared workstations should have sessions cleared after browser closure, but is there anything on our side that can assist here?

  • You could have a configurable option that decides what happens when a user clicks Logout in your app - SAML SLO or local session termination or ... . You could make this decision automagically without an option if you know the type of user (external vs internal) or whatever other input criteria you need. In general, SLO is not a good option – identigral Feb 7 at 3:15
1

I'm a fan of giving the user the choice in simple words. For example when they click logout, if they are in an SSO session, you can give them a popup with two options:

  1. Sign out of this app only (you can invalidate session tokens and at least make them go back to the IdP, but really this option doesn't do much).

  2. Sign out of all connected apps (this calls the IdP logout URL).

| improve this answer | |
0

I'm not quite sure if I understood your scenario, but I think that what you are looking for is called Single Logout.

You should configure your application to send a LogoutRequest to your IdP when the user signs of from it.
This should always be transparent to the final user. Never trust them to do the right thing.

This should be possible with most standard IdP and SP that you may use in your enterprise. Take a look at Single Logout Profile.

| improve this answer | |
  • Yes I am looking at Single Logout. The problem I have is for 90% of use cases the system is used internally and that users won't want to use single logout. They will just want to log out of the SP, as logging out of the IDP will log them out of email and everything else they use as part of their enterprise. Trying to support both cases in a secure and user friendly way so that they don't misunderstand what log out actually does. This seems like a downside of having an IDP for portal users vs staff where portal users will only use a single SP and want to log out of IDP vs staff with multiple SP – Cyassin Feb 6 at 2:52
  • Huum, let me know if I understood the issue. The user will logout from your SP in a shared workstation. If SLO is enabled, then it will kick him out of everything. If SLO is not enabled, they will be out of your SP, but the IdP session will be on that shared computer, right? – hess Feb 7 at 22:12
  • 1
    If that is the scenario, you may be looking at ForceAuth: stackoverflow.com/questions/23021870/… – hess Feb 7 at 22:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.