One method of Single Sign-On implementation is to make use of an LDAP server. As illustrated below, a user will log in to the “Portal A” application through the browser. The application validates the user information and generates an authorization identifier. Portal A will then route the request along with authorization identifier to the LDAP server.
The routed request is validated against the user information on the LDAP Server; if the user identification is successful the application will populate the user credentials along with the authorization identifier. When the user clicks on the Portal A for SSO site link, the application will send the user information to the “Portal B” application along with an authorization identifier. The Portal B application will route the request to the LDAP Server for user identification, and the user will be authenticated and identified against the user information at the LDAP store and will automatically log on to Portal B once the correct credentials are passed. (Khurana, 2012)
The benefits of the LDAP method of authentication are that it can be extended for integration with other enterprise systems such as ERP and CRM solutions. Additionally, the credentials of the end user are validated through the LDAP schema i.e. a set of rules that define what can be stored as entries in an LDAP directory. As the user information is in an encrypted format, it enhances the security of the system.
The shortcomings of LDAP authentication are the additional licensing and maintenance costs inherent to the LDAP server. LDAP authentication also needs enhanced network security to communicate with the applications, and application customization for integration with other system. (Khurana, 2012)
The Kerberos server provides a secure, single-sign-on, trusted, third-party mutual authentication service. One of the key reasons why Kerberos is secure is because it does not transmit passwords over the network in clear text, or cache passwords on the local user's hard disk. Instead, it makes use of “tickets” which are temporally limited cryptographic messages that prove a user's identity to a given server. To use Kerberos terminology, a ticket is a temporary set of electronic credentials that verify the identity of a client for a particular service.
Furthermore, once a user has authenticated to Kerberos at the start of the login session, those credentials are passed transparently to every other resource accessed during the day. This feature allows end-users to log in once to access all network resources that support Kerberos, thus providing single sign-on functionality.
Kerberos is a trusted third-party, because the service works through a centralized authentication server that all systems in the network trust and all authentication requests are routed through the centralized Kerberos server.
Kerberos’ mutual authentication ensures that not only is the person behind the keyboard who he claims to be, but also proves that the server he is communicating with is who it claims to be. Mutual authentication protects the confidentiality of sensitive information by ensuring that the service the user is communicating with is genuine. (Garman, 2004)
The operational steps of Kerberos consist of the user’s client, alternatively known as a principal, contacting the Key Distribution Center (KDC) to authenticate, and the KDC sending a session key to the user encrypted with the user’s secret key. A principal or principal name, is the the unique name of a user or service allowed to authenticate using Kerberos.
The KDC sends a Ticket Granting Ticket (TGT) encrypted with Ticket Granting Service’s (TGS) secret key. The user’s client will decrypt the session key and use it to request permission to an appication from the TGS.
The TGS then verifies the user’s session key and sends the user a Client Server (C/S) session key to use to access the appication. The TGS also sends a service ticket, encrypted with the applications’ private key. The Client connects to the application, the application sees a valid C/S session key and knows the user has permission to access it, as well as that the user is an authentic user.
NTLM is a suite of authentication and session security protocols used in various Microsoft network protocol implementations and is supported by the NTLM Security Support Provider (NTLMSSP). NTLM is also used throughout Microsoft systems as an integrated single sign-on mechanism.
NTLM provides a challenge-response authentication mechanism, in which clients are able to prove their identities without sending a password to the server. The NTLMSSP also provides a means of applying a digital signature to a message, which ensures that the signed message has not been modified, and that that signing party has knowledge of a shared secret. NTLM implements a symmetric signature scheme (Message Authentication Code, or MAC) which is a valid signature that can only be generated and verified by parties that possess the common shared key.
A message authentication code (MAC) is an authentication tag, also known as a checksum. It is generated by combining an authentication scheme with a secret key to a message. As contrasted with digital signatures, MACs are computed and verified with the same key, so that they can only be verified by the intended recipient. There are four types of MACs: The unconditionally secure, hash function-based, stream cipher-based, and the block cipher-based.
The NTLMSSP implements a symmetric-key encryption mechanism, which provides message confidentiality. In the case of NTLM, sealing connotes signing, though a signed message is not necessarily sealed, however all sealed messages are signed.
NTLM has been largely displaced by Kerberos as the authentication protocol of choice for domain-based scenarios. However, Kerberos is a trusted-third-party scheme, and cannot be used in situations where no trusted third party exists; i.e. member servers (servers that are not part of a domain), local accounts, and authentication to resources in an untrusted domain. In such scenarios, NTLM continues to be the primary authentication mechanism. (Glass, 2006)
Enterprise Single Sign-On (ESSO) Solutions
The open source Shibboleth ESSO functions in the same manner as other web-based SSO systems. What is unique about Shibboleth is its adherence to standards and its ability to provide Single Sign-on support to services outside of a user's organization while protecting their privacy.
The main components of a web-based SSO system are: The web browser that represents the user within the SSO process. A further component is the resource, which contains the access-restricted content that the user wants. Additionally, there is the Identity Provider (IDP), which authenticates the user, and the Service Provider (SP), which performs the SSO process for the resource.
The first step in Shibboleth SSO is the user attempting to access the protected resource. The resources determines if the user has an active session and, discovering that they do not, sends them to the SP in order to start the SSO process. The SP software which is typically installed on the same server as the resource will issue an authentication request, which is sent to the IDP. When the request arrives at the IDP, it checks to see if the user has an existing session. If there is an existing session, the user will proceed to the next step. If there is not an existing session the IDP will prompt them for their username and password, and if correct, allow the user to proceed to the next step.
With the user having been identified, the IDP will prepare an authentication response and send it and the user back to the SP. When the user arrives with the response from the IDP the SP will validate the response and create a session for the user, and provide the user's identifier to the protected resource, whereupon the user is sent to the resource. Once again the user is attempting to access the protected resource, however there is now a session in existence and the resource will service the user's request and provide the requested data.
The basic steps during an Oracle ESSO enabled application logon consist of an end-user requesting access to an enterprise application. The request can be to a Windows, mainframe, web or Java-based application, or external portal. The ESSO Logon Manager Agent intercepts the user request on his desktop, retrieves the user record and then fills in the appropriate credentials for the ESSO enabled application. The application-specific username and password will then be sent to the application, and the end-user is granted access to the application.
The Oracle ESSO suite consists of five components; the first is the ESSO Logon Manager (ESSO-LM) which provides an interface for single sign-on functionality to network and computer logons as well as to applications. The second component is the ESSO Logon Manager Admin Console, which interacts with the Logon Manager and facilitates management and administration of ESSO attributes. The third component is the ESSO Password Reset (ESSO-PR) which provides a recovery mechanism directly from the Windows logon prompt for users who forget their desktop passwords.
The ESSO Kiosk Manager (ESSO-KM) is the fourth component, and it provides initial user authentication and automatic user sign-off to kiosk environments, enabling secure kiosk computing at any location within the enterprise. The system monitors unattended kiosk sessions, and inactive sessions are protected by a secure screen saver, which permits the next user to sign on to a new session while safely terminating the prior session.
The ESSO Authentication Manager (ESSO-AM) allows entities to use any combination of tokens, smart cards, biometrics and passwords to control user access to their applications, thus facilitating authentication strategies. The ESSO Provisioning Gateway (ESSO-PG) allows system administrators to directly distribute user credentials, usernames and passwords to the ESSO. The administrator can add credentials for new applications and new users as well as modify or delete old credentials to the ESSO. The Provisioning Gateway is also the interface that is used to integrate the Oracle Identity Manager (OIM) which enables provisioning of users to all enterprise applications and enables Oracle ESSO.
The figure below depicts the components of the ESSO. The ESSOLM agent and the ESSO-LM admin console form the base components and all the other components are offered as add-on modules. The ESSO-LM is the primary component for detecting requests for credentials, analyzing the response necessary, responding, logging events and administering settings. (Muthanna, 2009)
RSA Security's ClearTrust 5.5 is designed to deliver SSO through federated identity, user management support and dynamic transactional authorization for multi-partner Web services. To accomplish this, ClearTrust 5.5 provides SAML-based identity and authentication via a Federated Identity Management (FIM) module. The ClearTrust 5.5 version release also provided an automated workflow to authorize account creation, group assignment, profile updates and password resets. It also includes transactional Smart Rules, which enable dynamic look up in databases and LDAP directories to support authorization decisions. (Wrenn, 2006)
As previously discussed, FIM enables Security Assertion Markup Language (SAML) an Extensible Markup Language (XML) standard that allows a user to log on once for affiliated but separate Web sites. SAML specifies three components: assertions, protocol, and binding. There are three assertions: authentication, attribute, and authorization. The authentication assertion validates the user's identity, and the attribute assertion contains specific information about the user. The authorization assertion identifies what the user is authorized to do.
Asserting and relying parties. The Asserting Party is the party that requests access to a resource on a Relying Party's site. The Relying Party accepts SAML assertions, which are statements that declare that the identity of a user has been authenticated. Trust relations are established by defining the Asserting Party and the Relying Party enables one identity to be mapped to multiple identities on other sites to eliminate the need to enter and re-enter user-names and passwords. (Wrenn, 2006)
There are many benefits to the implementation and usage of an Enterprise Single Sign-on (ESSO) solution. An ESSO can aid in facilitating regulatory compliance, such as Sarbanes-Oxley and HIPAA compliance mandates. There is the ability to enforce stronger and more consistent password and process policies across synchronized systems. An ESSO can also aid in simplifying compliance with audit requirements, and provide administrator application access review and removal of a user. Network security is further enhanced, as unauthorized users are prevented from accessing enterprise applications, though legitimate end-users are able to obtain quick and easy access from any location.
Deployment of an ESSO can enable virtually every enterprise to realize significant cost-savings and rapid ROI. By utilizing an ESSO, enterprise end-users have just one password to remember, as a result passwords are forgotten less often. This reduces both help desk costs associated with forgotten passwords and the associated loss of productivity. An average enterprise spends about $25 on a help desk call, and 40% to 60% of calls to help desk are password-related. An ESSO will improve user productivity and satisfaction through intuitive self-service password reset.
However, there are a number of clear and apparent disadvantages to an ESSO as well. End users have just one password to remember, which increases the chance that it could be compromised and allow unauthorized users to gain access to all systems to which the password is associated. Then too, not all systems support bi-directional password synchronization; as such password policies may not be compatible across all systems. Moreover, deployment and implementation can be complex as agents are required on all target systems.