3

Many cloud SSO providers now offer "password based SSO" (e.g. https://docs.microsoft.com/en-us/azure/active-directory/active-directory-appssoaccess-whatis ), where, even if the SaaS you want to log in to doesn't support SAML or the like, you can still do SSO, because the SSO service will parse the HTML, store your password, and log you in to the 3rd party SaaS app.

Microsoft is advertising this. And, for example, if you do a Google search of "Gusto SSO", you'll see many others that advertise it. (I pick on Gusto, because they have no SAML, and you can see from all the SSO services that claim they support it that it is an autogenerated template...).

Now, to me this is a major vulnerability: The main reason we want SSO is so that when we onboard someone, we do it in one place, and when they leave, we have only one password to revoke: not dozens. Otherwise, you're bound to forget that they also have the password to randomsaas.com...

But, that only works if the password doesnt go through their browser. If it's a password based SSO, and the SSO app is just autotyping their login the login goes through their browser, and so, they can sniff and store it. Therefore, even if you revoke the users SSO, they can still have stored the password.

Is there any solution for this?

SRobertJames
  • 31
  • 1

1 Answers1

3

Technically the Password-based Single Sign-On from Azure AD (from your link) is not an SSO solution but a password management one. The external application has its own credentials including password, and a plugin installed in the browser types them into an HTML form on behalf of the user, exactly what Lastpass does.

That means that those credentials have to been managed individually: created for a new users and revoked if user leaves. No doing so will indeed leave open security breaches, and the linked page in clear on that point even when credentials are managed by an administrator (emphasize mine):

The credentials are obfuscated from the end user during the automated sign in process; however they are technically discoverable by the user using web-debugging tools, and users and administrators should follow the same security policies as if the credentials were presented directly by the user.

That means that you should have different credentials for each user and individually revoke them if the user leaves.

Only in true SSO solutions like SAML or CAS where there is one single account shared by multiple applications you have one single password to revoke.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84