SSO properly stands for Single Sign-On, though it is sometimes used to mean Same Sign-On. These should not be confused, though they often are, and sometimes deliberately!
What’s SSO for?
Typically, in any organization of size, users will need access to many IT systems, for example, AD, SAP, Azure AD, an HR system, SalesForce, legacy systems and so on. Without SSO of any kind, users may have to remember a different username and password (different credentials) in each system. This is at best annoying for users. At worst can lead to poor password hygiene, such as short/simple passwords, or passwords being written down on a post-it note.
A degree of alignment can be enforced manually such as same username, and even the same password. This improves the user experience. Whether it is more or less secure is a matter for debate: we may have removed the post-it note problem, but added others. For example, if someone can “crack” the least secure system, they might gain credentials that allow access to other, more important systems.
Using a product like MIM (or FIM) usernames can readily be synchronized between on-premises systems (and even some cloud systems), and this can be extended to passwords too (though the mechanism is a little different). Similarly AAD Connect can synchronize credentials between AD and Azure AD. This is what we call Same Sign-On. Each time a user tries to access a system, they have to log on, but they use the same username and password everywhere (or at least everywhere included in the SSO).
A more “grown-up” solution is Single Sign-On, that is, you sign on once, and then you get access to everything you need for a period of time, or for the duration of your session. At one extreme it can be seamless, slick and secure but it can also be a bit clunky, and less secure. Legacy on-premises SSO can work at the level of “screen-scraping” – software detecting what you type as you log in to a system, remembering that and then “playing it back” next time. If you use Office 365 (which means you are really using Azure AD), and your MyApps portal includes links to SalesForce, Box, Yammer, Twitter etc. – it’s pretty slick. Although even here the way it handles each app can vary – SalesForce is “aware” of Azure AD as an authentication mechanism, while for Twitter Azure AD remembers the username and password used to access Twitter.
An important piece of SSO is that between AD and Azure AD – important because it can help make migration from AD to Azure AD (and the inevitable degree of co-existence of legacy on-premises systems with cloud applications) more friction-free. When you install AAD Connect it can synchronize credentials (Same Sign-On), or you can go for true Single-Sign-On in one of two ways: 1) using ADFS (with all the additional infrastructure that implies), or 2) use “Pass Through Authentication” (which is relatively new).
Need help with SSO in your organization? Our team of consultants is ready to advise. Contact us.