In this tip, we'll learn about some of the challenges of identity management and how deploying SSO can solve some of those problems. We'll also discuss why SSO is important, introduce some of the more popular products.
Identity management revolves around the following essential areas: management of identities, access control and directory services. Regarding management of identities (accounts and user access), there are many challenges to properly maintaining identities. Some of these include the creation of the accounts, as well as the maintenance and deletion of them. Another is how best to provide for authentication to users. This can involve password policies and/or biometrics. How do we validate users' credentials in such a way as to protect the company, while at the same time easing the pain involved in having to authenticate users to multiple on-line systems?
The burden taken on with the administration of accounts grows as the number of these systems that are deployed increases. This is where single sign-on (SSO) and identity management come together. Appropriate implementation of such a system will substantially reduce the overall administrative work that is necessary when managing user information in a centralized repository. Let's first describe some of the problems that this system solves:
- Too many teams involved in the user administration, leading to a large system administration overhead
- Accounts which are created by staff that have unauthorized system access rights.
- Lack of standardized IDs, leading to different login IDs for the same user and different policies for systems.
- Slow response time to maintaining IDs, because of the inherent bureaucracy of maintaining disparate systems and coordinating (systems administration and the help desk) all the different authentication policies between multiple groups.
- Compliance and regulatory issues (Sarbanes-Oxley, HIPPA), as a result of poorly defined and documented systems with a lack of fully-defined audit trails.
- Redundant or incorrect information that poorly identifies directories and identities.
Perhaps the biggest issue here is that while some companies acknowledge the problem, they also recognize the problems with doing nothing to solve it, without looking long-term and facing the actual matter.
Applications can use the single sign-on system to provide users with seamless access to content that is stored and managed on many different types of systems. This is done in a way that allows them to log on multiple times, with the same password. SSO is a methodology which provides for a single action of user authentication and authorization. It allows the user to access all computers and systems where he has access permission, without the need to enter multiple passwords. In providing this function, it substantially reduces human error, a major component of systems failure. Perhaps the most important component of a having a centralized system is having a central repository where usernames and passwords are kept. SSO solves the problem of having separate applications keeping their own database of users, passwords and permissions. Connecting a group of applications through an integrated system, enables both internal and external customers to use the same username and password with multiple sites and applications.
Some ways of implementing SSO include Enterprise Sign on Engine, JA-SIG, CoSign, Enterprise single sign-on (E-SSO) and Kerberos. Let's start with JA-SIG. The JA-SIG Central Authentication Service (CAS) was originally developed by Yale University, before it became the JA-SIG project.
JA-SIG CAS is Web-based SSO that works with applications accessed by a Web browser. The initial request to a Web system is diverted to a separate authentication system and only returned back after it is successfully authenticated. The system functions as a type of proxy which redirects the request to the authentication server. CAS still needs a way to authenticate credentials. A very popular way of authenticating CAS credentials is by way of using a link from the system to your LDAP server.
What about Kerberos? Kerberos is used for applications to entirely externalize authentication. Users log into a Kerberos Server and are issued a ticket, which the client presents to the server. While Kerberos is available on many platforms, including Unix, it usually requires a great deal of modification to the application code.
Let's get back to LDAP for a minute. What is important to remember is that LDAP is not really an authentication protocol. It's a protocol for accessing directories, for identification purposes. Kerberos is a much better choice for authentication of users, particularly considering its SSO features. Some versions of LDAP, such as IBM Tivoli Directory Server, allow one to choose your authentication strategy; you can use either a simple user ID and password authentication or the more secure digital certificate-based authentication structure. Kerberos also support SSL.
LDAP actually works very well with SSO-type systems and most SSO systems use LDAP authentication on the back-end. How do they do that? The user logs on and sees the typical corporate login. After entering their ID and password, the SSO software takes the information and sends it to the security server using an encrypted connection. This server then logs on to the LDAP server, which stores the passwords. When this is accomplished, the security server takes the authentication information and allows the user to go to where they need to.
This was first published in June 2007