Single Sign-on Considerations
Because of the popularity of SSOs and its complexity of issues, it serves as a great example of interdependent policy, technology, and business process.
The benefits of coordination and integration of authentication into an Single Sign-on system are well established, and include:
Improved security through the reduced need for a user to manage and remember multiple sets of authentication information.
Consolidated account management interface through which all the component authentication systems may be managed in a coordinated and synchronized manner.
Reduced system administration overhead and response time in adding users or modifying access rights improves security by maintaining the integrity of user account configuration, including the ability to inhibit or remove a user’s access to all system resources in a coordinated and consistent manner.
On the other hand, there are non-trivial risks with implementing SSOs, and organizations should consider the following:
Organizations must have systems that manage authentication and authorization as separate and distinguishable processes. Otherwise, an SSO system may introduce an unacceptable risk.
Users are known to share their credentials with a friend and co-worker to access their email, documents, or homework problems. If the organization extends the use of this credential by implementing an SSO, the shared credential can then be used to access critical application functions the user may not have intended to share, such as performing assessments, submitting financial information, modifying benefit enrollments, or accessing transcripts. Once organizations recognize this potential for credential sharing, they often become much more concerned about who is really accessing and modifying application data.
Some applications (such as test taking) require verification that the identified person is the same one using the workstation. In an SSO design, the person may have completed the single login task several hours ago, which may not be sufficient verification for the application. While some SSO systems allow an application to force a re-login, many do not.
An application must trust a 3rd party authentication system to correctly assert the identity and authentication credentials of a user and protect the authentication credentials used to verify the user’s identity to the secondary domain from unauthorized use.
The authentication credentials must be protected during transfer between the primary and secondary domains against threats that may lead to masquerade attacks, such as interception or eavesdropping.
An SSO may most reasonably be achieved for a defined domain of similar applications or systems that have similar security requirements. Despite the appeal of SSO, business or security drivers may justifiably lead organizations to maintain multiple authentication systems.
Given this, a more realistic goal would be reduced sign-on, which limits the number of authentication systems, resulting in fewer user credential data stores and processes to manage, as well as fewer user authentication methods.