Understanding Single Sign-On (SSO)
As discussed, business users today must log into a variety of applications, which may reside on many different servers. The users, therefore, must manage numerous username and password combinations. To simplify user access to multiple systems, many companies now use single sign-on (SSO) software, which, as shown in FIGURE 5-1, requires the user to sign on one time. Behind the scenes, then, the single sign-on software manages the user’s access to other systems. In this way, a user need only remember one username and password. After logging in, users can access other systems as if they had logged into each individually.
FIGURE 5-1 A single sign-on system lets a user log into a system one time and then move freely between related servers and applications without having to authenticate himself or herself each time.
Single sign-on software includes the following advantages:
-
Users have fewer username and password combinations to remember and manage.
-
Users experience less “password fatigue” caused by the stress of managing multiple passwords.
-
Less user time is consumed logging into individual systems.
-
Help-desk teams experience fewer calls for forgotten passwords.
-
IT staff has a centralized location for password compliance and reporting.
The primary disadvantage of single sign-on systems is the potential for a single source of failure. Should the authentication server fail, users will not be able to log into other servers. Thus, having a cloud-based authentication server with system redundancy reduces the risk of system unavailability.
Understanding How SSO Works
Although different implementations of SSO exist, many solutions employ a secure ticket. When a user logs into the authentication server, he or she is given a secure ticket. Later, when the user accesses a server, that server, in turn, validates the ticket with the authentication server. The authentication server, as shown in FIGURE 5-2, not only confirms that the user is authorized to use the server, it may also provide the user’s access rights specific to that server.
FIGURE 5-2 SSO systems often assign authenticated users a ticket, which the software presents behind the scenes to the servers the user accesses. Each server can use the ticket to determine the user’s access rights on that particular server.
Should an employee leave the company, the IT staff need only disable the user at the authentication server to disable the user’s access to all systems.
Understanding Federated Identity Management
As you examine SSO, you may encounter the term federated identity management (FIDM). In short, FIDM describes the technologies and protocols that combine to enable a user to bring security credentials across different security domains (different servers running potentially different operating systems). As you examine FIDM, keep in mind the four As of identity management:
-
Authentication: The process of determining and validating a user for on-premise as well as cloud-based solutions.
-
Authorization: The process of determining and specifying what the user is allowed to do on each server.
-
Account Management: The process of synchronizing user accounts by provisioning and deprovisioning access.
-
Audit Logging: The process of tracking which applications users access and when.
Behind the scenes, many FIDM systems often use the Security Assertion Markup Language (SAML) to package a user’s security credentials, as shown in FIGURE 5-3. For specifics on SAML, visit the SAML website at www.saml.xml.org.
FIGURE 5-3 SAML allows software to package user-security credentials.
Understanding Account Provisioning
In many companies, when an employee is hired, the human-resources department sends an email to the IT staff, who, in turn, create a user account for the employee. Sometime during the employee’s first week, his or her manager will decide that the employee needs to access other systems. The manager, in turn, will send additional emails to the IT staff requesting various account access. The process of creating a user account on a system is account provisioning. As you might guess, because different employees may need different capabilities on each system, the provisioning process can be complex.
When an employee leaves the company, a deprovisioning process must occur that removes the user accounts. Unfortunately, the IT staff is not always immediately informed that an employee no longer works with the company, or the IT staff misses a server account, and the user may still have access to one or more systems.