SSO means a session authentication process that allows users to create a single set of credentials that can be used to access multiple sites or applications network wide.
What is single sign on?
Single Sign On (SSO) (also known as Enterprise Single Sign On or "ESSO") is the ability for a user to enter the same id and password to login to multiple applications within an enterprise. As passwords are the least secure authentication mechanism, single sign on has now become known as reduced sign on (RSO) since more than one type of authentication mechanism is used according to enterprise risk models.
For example, in an enterprise using SSO software, the user logs on with their id and password. This gains them access to low risk information and multiple applications such as the enterprise portal. However, when the user tries to access higher risk applications and information, like a payroll system, the single sign on software requires them to use a stronger form of authentication. This may include digital certificates, security tokens, smart cards, biometrics or combinations thereof.
Single sign on can also take place between enterprises using federated authentication. For example, a business partner's employee may successfully log on to their enterprise system. When they click on a link to your enterprise's application, the business partner's single sign on system will provide a security assertion token to your enterprise using a protocol like SAML, Liberty Alliance, WS Federation or Shibboleth. Your enterprise's SSO software receives the token, checks it, and then allows the business partner's employee to access your enterprise application without having to sign on.
Single sign on federated authentication also works with your employees. For example, an employee who is trying to access your outsourced benefits supplier to update their benefits information would click on the benefits link on your intranet. Your enterprise's single sign on software would then send a security assertion token to the benefits supplier. The benefits supplier's SSO system would then take the token, check it and grant access to your employee without making them sign on.
Single Sign On Benefits
Single sign on benefits are:
Ability to enforce uniform enterprise authentication and/or authorization policies across the enterprise
End to end user audit sessions to improve security reporting and auditing
Removes application developers from having to understand and implement identity security in their applications
Usually results in significant password help desk cost savings
Since the internet is stateless, this means that the single sign on software must check every request by the user's browser to see if there is an authentication policy pertaining to the resource or application the user is trying to access. In a medium to large enterprise, this means that every time the user clicks on a different URL, there is traffic between the user's browser, the web or application servers and the security server. This traffic can become large and cumbersome from a performance perspective. Therefore, most modern single sign on systems use LDAP (Lightweight Directory Access Protocol) directories to store the authentication and authorization policies. The LDAP directories are made for high performance lookups thus addressing the high traffic load. Further, the LDAP directories are often the source for the single sign on system to authenticate against.
Single sign on systems in medium to large enterprises can become a single point of enterprise failure if not properly designed. If the single sign on system goes down but the applications remain up, no user can access any resource or application protected by the SSO system. Many enterprises have experienced this painful condition resulting in productivity loss. Therefore, it is essential that your enterprise single sign on system have a good and well tested failover and disaster recovery design.
Finally, single sign on systems in medium to large enterprises requires good identity data governance. Enterprise security features being offered by the single sign on system is only as good as the underlying identity data. Thus it is critical that all enterprise identity data have good, quick business processes that pick up on any change to the identity such as new identity creation, identity termination or role changes. Without this, enterprise SSO systems are vulnerable to creating enterprise security holes.
Single sign-on (SSO)is a session/user authentication process that permits a user to enter one name and password in order to access multiple applications.
In other words, it is mechanism whereby a single action of user authentication and authorization can permit a user to access all computers and systems where
he has access permission, without the need to enter multiple passwords. Single sign-on reduces human error, a major component of systems failure and is therefore
highly desirable but difficult to implement.As IT systems proliferate to support business processes, users and system administrators are faced with an increasingly
complicated interface to accomplish their job functions. Users typically have to sign-on to multiple systems, necessitating an equivalent number of sign-on dialogues,
each of which may involve different usernames and authentication information. System administrators are faced with managing user accounts within each of the multiple
systems to be accessed in a co-ordinated manner in order to maintain the integrity of security policy enforcement.Historically a distributed system has been assembled from components that act as independent security domains. These components comprise individual platforms with associated operating system and applications.
These components act as independent domains in the sense that an end-user has to identify and authenticate himself independently to each of the domains with which he wishes to interact. This scenario is illustrated above. The end user interacts initially with a Primary Domain to establish a session with that primary domain. This is termed the Primary Domain Sign-On in the above diagram and requires the end user to supply a set of user credentials applicable to the primary domain, for example a username and password. The primary domain session is typically represented by an operating system session shell executed on the end user’s workstation within an environment representative of the end user (e.g., process atrributes, environment variables and home directory). From this primary domain session shell the user is able to invoke the services of the other domains, such as platforms or applications.
To invoke the services of a secondary domain an end user is required to perform a Secondary Domain Sign-on. This requires the end user to supply a further set of user credentials applicable to that secondary domain. An end user has to conduct a separate sign-on dialogue with each secondary domain that the end user requires to use. The secondary domain session is typically represented by an operating system shell or an application shell, again within an environment representative of the end user. From the management perspective the legacy approach requires independent management of each domain and the use of multiple user account management interfaces. Considerations of both usability and security give rise to a need to co-ordinate and where possible integrate user sign-on functions and user account management functions for the multitude of different domains now found within an enterprise.
A service that provides such co-ordination and integration can provide real cost benefits to an enterprise through:
reduction in the time taken by users in sign-on operations to individual domains, including reducing the possibility of such sign-on operations failing
improved security through the reduced need for a user to handle and remember multiple sets of authentication information.
reduction in the time taken, and improved response, by system administrators in adding and removing users to the system or modifying their access rights.
improved security through the enhanced ability of system administrators to maintain the integrity of user account configuration including the ability to inhibit
or remove an individual user’s access to all system resources in a co-ordinated and consistent manner.Such a service has been termed Single Sign-On after the end-user perception of the impact of this service. However, both the end-user and management aspects of the service are equally important. This approach is illustrated in the diagram above. In the single sign-on approach the system is required to collect from the user as, part of the primary sign-on, all the identification and user credential information necessary to support the authentication of the user to each of the secondary domains that the user may potentially require to interact with. The information supplied by the user is then used by Single Sign-On Services within the primary domain to support the authentication of the end user to each of the secondary domains with which the user actually requests to interact.
The information supplied by the end-user as part of the Primary Domain Sign-On procedure may be used in support of secondary domain sign-on in several ways:
Directly, the information supplied by the user is passed to a secondary domain as part of a secondary sign-on.
Indirectly, the information supplied by the user is used to retrieve other user identification and user credential information stored within the a single sign-on management information base. The retrieved information is then used as the basis for a secondary domain sign-on operation.
Immediately, to establish a session with a secondary domain as part of the initial session establishment. This implies that application clients are automatically invoked and communications established at the time of the primary sign-on operation.
Temorarily stored or cached and used at the time a request for the secondary domain services is made by the end-user.
From a management perspective the single sign-on model provides a single user account management interface through which all the component domains may be managed in a coordinated and synchronised manner.
Significant security aspects of the Single Sign-On model are:
the secondary domains have to trust the primary domain to:
correctly assert the identity and authentication credentials of the end user,
protect the authentication credentials used to verify the end user identity to the secondary domain from unauthorised use.
The authentication credentials have to be protected when transfered between the primary and secondary domains against threats arising from interception or eavsdropping leading to possible masquerade attacks.