The Basics of SSO (Single Sign On)
SSO stands for Single Sign On and it is exactly what it sounds like. An SSO is put in place simply for convenience to the user by creating a simple one-stop log in. You may not be aware, but you probably sign in through one each time you visit your favorite website or application. Have you ever seen an option that allows you to sign-in or create an account using your pre-existing Google, Facebook, or other account information? This is a prime example of SSO. The site is pulling your authentication data from your Facebook account and replicating those credentials in its own system. Makes it a lot easier to sign in that way, huh? Websites can pull its data from multiple different sources and can consists of many different integrated systems to manage its data.
What is an SSO?
An SSO allow websites and applications to integrate their authentications so that a user only needs to sign in once, and remember only one set of credentials, but have access to all applications. This means users don’t have to identify themselves, or log in, multiple times through each service or system used throughout their experience with an organization. Large websites will often have multiple systems integrated together to achieve the most functionality. However, these services might all have very different and unique authentication processes, requirements, and may be different websites entirely.
If there are several external systems your organization’s internet ecosystem, you will most likely consider incorporating an SSO to integrate the systems for a simple log-in process. For example, if you have a site that uses a CMS (Content Management System), an AMS (Association Management System) and a CRM (Customer Relationship Management), you don't want users to have to log in to each individually. This would take up a lot of time, and frankly, is a hassle. That’s where Single Sign On comes into play.
How does it work?
An SSO is determined between the multiple systems involved in the website so that the user’s authentication data and credentials are linked and recognized between each system. This means that the user will have one set of credentials to access each system within that website or application, given they have the right permissions. By logging into one, they are automatically logged into the rest.
You may be familiar with the term “cookies.” You can think of cookies as the memory of the web page. It allows the web page to recognize the actions you took within the site, saving that data so you will not have to enter that piece of information more than once. SSO works by using cookie sessions. A session ID is the unique number that is generated each time you open your browser. Each time you close out your browser and reopen it, that number changes. Sessions can be local, meaning your time spent is sustained within the application or site. If there is an SSO, then it is known as an Authorization Server Session. If you use an identity provider, like Facebook in my example above, this is called an Identity Provider Session.
Most SSOs operate off a hub and spoke model. While there are other SSO models out there, we’ll focus on this model as it is the most prevalent and easy to understand. Each domain within the SSO is managed by a central domain that does the authentication and shares the session information with the systems’ domain to know if access can be granted. The “hub” is the Authentication Server and the “spokes” are the web pages or applications affiliated with them.
This may be a bit confusing to comprehend, so here is an example:
A user, we will call him “Bob,” is a paying member of www.thiswebsite.com and would like to log in. www.thiswebsite.com is an association and uses and AMS (Association Management System) to manage all of their users, including their usernames and passwords. Bob navigates to www.thiswebsite.com and is prompted to log in with his username and password. He types in his username and password credentials and clicks “Log in.”
For Bob, this is the extent of it. A couple seconds pass, and he is logged in successfully. The site he just logged in to, www.thiswebsite.com, manages its data between two systems, a CMS and an AMS. What Bob might not realize, is that he was successfully logged into both of these systems in a single click. Neat, right? Bob can now visit a webpage on the AMS and not need to login again as if it were a completely separate system.
During those seconds between when he clicked “Log in” and when he was granted access, a couple things happened. The SSO sent a request with his credentials to the AMS, which stores his user data. The credentials he provided matched the credentials in the AMS, and logs him in successfully.
At the basic level, the SSO grants his access to the site, however, for the purpose of this explanation, www.thiswebsite.com has an integrated SSO. The AMS confirms and notifies the SSO that he is a “member” (Membership: Annual) until “December 1, 2020” (End date: 12/01/2020).
The SSO sends this additional information (username, membership status, and end date) to the CMS and updates it. This data is rewritten in the CMS each time he logs in. If Bob were to change his name, that new name will not be updated in the CMS until sends a request to log in. By doing this, the SSO is recognizing not only his log in credentials but is also recognizing his user role. With a specific user role associated with this user, it creates a way for the organization or website owner to grant access to certain features and pages of the website to be only accessible by specific roles. This comes in handy for organizations who choose to have multiple membership options and levels. This is something your friendly developer can set up for you.
Reap the Benefits
Besides the convenience for users to log in to multiple systems using one set of log in credentials, it is also cost effective to the organization that owns the site. Since users do not have to memorize multiple passwords, it significantly decreases the number of IT requests to change forgotten/lost passwords, which in return, will save the IT department’s time for more urgent and pressing issues. This is also true for system administrators, who will save time because their ability to enable and disable user access to the multiple systems, pages, applications, etc. will be simpler to manage in a centralized, single place.
With an SSO, resources and data are integrated and recorded, keeping logs and reports of what was accessed and by who. Since only one system controls the credentials instead of multiple, user credentials are more secure.
Those who utilize an SSO claim it drastically improves workflow, meaning it saves the users’ time. By logging into the site in one click, the user faces less obstacles to achieve their desired actions.
If you have questions, or want to learn more about SSO, reach out to your Client Manager at Vanguard.