SSO… what does it really mean?
For some time now we have understood SSO to mean Single Sign On, but lately I’ve been hearing folks in the Office 365 world use SSO to mean more than one thing. In fact, I’ve seen them use this term to refer to three different things that are all similar yet should not be confused. So let’s clear this up and discuss when and where to use each of these authentication models.
So let’s talk about the one we know first…
SSO = Single Sign On
Office 365 Single Sign On means that you are using your own Active Directory to authenticate users in Office 365.
In the example below, a user attempts to log into the Office 365 portal and is then redirected to an Active Directory Federation Services server (ADFS), which will then communicate with Active Directory to authenticate that user.
This is a VERY simplified version of the process, but the thing here to remember is the authentication happens on your Active Directory. This is an important distinction, because in the event your Active Directory is not available, you will not be able to log into Office 365.
There are some pretty good reasons to do this, but for most deployments allowing Office 365 to authenticate the user is the most desirable configuration.
At the other end of the spectrum…
SSO = Separate Sign On
Separate Sign On is just what it sounds like: you have a different username and password for Active Directory and for Office 365. In this configuration, Office 365 doesn’t know about Active Directory and vice versa. In the example below you can see there is a client logging into Office 365 and Office 365 is doing the authentication.
Although this is fine for very small organizations, it requires twice the administration. Every user who is in Active Directory Must also be created in Office 365. In small environments this extra duty may not be an issue. In larger organizations dual administration becomes unwieldy and prone to errors.
And the happy medium?
SSO = Same Sign On
Same Sign On is the sweet spot for most Office 365 deployments because it allows you to create users in Active Directory (just like Single Sign On) but it allows Office 365 to do the authentication.
It manages this through a component (also used in Single Sign On) called Directory Synchronization, or DirSync. DirSync replicates users and passwords from Active Directory to Office 365, but allows Office 365 to do all the authentication. This means that in the event a backhoe cuts through the fiber line for your ISP and your servers can’t talk to Office 365, your users can still authenticate and they get to use the username and password from Active Directory to do it.
In the example below, users from Active Directory are being synchronized to Office 365. When a user attempts to log into Office 365 the will then use the credentials from Active Directory to authenticate the user.
So what have we learned?
- When you hear someone talking about SSO and Office 365, they may not mean what you think they mean.
- Where authentication happens is important.
- Each of these scenarios require a lot of forethought and preparation.
Since Same Sign On will be the desired deployment for most organizations, I will review all the components of Same Sign On and how they interact (along with a few caveats) in an upcoming post.