PistolStar's College of Authentication: SSO 101

Course Description

PistolStar is now proud to introduce our College of Authentication. Due to our team's wide array of authentication knowledge and expertise, we have begun to compile that knowledge into educational materials, to share with our valued contacts. The first lesson, SSO 101, gives a brief overview of each type of SSO, which we will be exploring in greater depth throughout the year.

Types of Single Sign-on:

True SSO

True SSO is the ability to provide your credentials one time during your computer session and not be asked for credentials again. This is done by leveraging those credentials when navigating to other resources during your session that will also require you to verify your identity.

Sometimes SSO is referred to as having the passwords for all protected resources synchronized, or Password Synchronization. This is not true SSO as the user has to enter the same password more than once, which can slow down productivity if asked for it enough times during the day. The user also has the onerous task of remembering the user ID for each system., if the password is compromised for one resource, all resources are affected.

True SSO requires the password once, usually when the user logs onto their desktop machine at the beginning of their work day.

Some implementations of True SSO use the same password and user ID against a central database to authenticate a user as they access additional protected resources throughout the day.

Also employed for True SSO is the use of a security key. Once the user has been authenticated with their user ID and password the first time, the authenticating server also provides the user with an encrypted token or key which will be used as identification for future access to resources that know how to decrypt the token and recognize the user as authenticated.

Session-based SSO

A user's initial logon to a HTTP server through a web browser results in a session token being generated on the server and returned to the user as an in-memory cookie. From then on, SSO is accomplished by presenting the session token to the server as proof of authentication. The server or an installed agent verifies the session is valid and unexpired before it looks up the associated identity and returns it to the server.

Session Single Sign On offers a user the convenience of logging into a server or domain once and not having to login again to access resources in the same domain or on different servers.

The basics of Session SSO are an initial authentication, the creation of a session token, and resources that know how to authenticate the user with the session token.

• Initial Authentication – some means of the user verifying their identity for the resource server. The credentials are usually in the form of a username and password pair.
• Session Token – the cookie that contains the information required to authenticate the user automatically
• Session – the time that a user is actively logged onto a resource with a cookie
• Session Server – the server that performs the original authentication, establishes the session in a database or cache and provides the session cookie to the client
• Token validation – implemented a number of ways. Some systems have a central session server that can validate the token. Other systems have applications that can register and participate in using the token for validation

Session SSO for single or multiple servers:

Single Server Session SSO

A user authenticates to a server and any additional resources on that server requested by the same user during the session will not require authentication as the cookie/token will be present with the request. Resources on a different server will require the user to enter credentials again.

Multiple Servers/Same Domain Session SSO

A user accesses a web server using a fully-qualified domain name (FQDN), e.g. "mail.acme.com", and authenticates to it as required.The web server responds to the successful authentication by returning a session cookie that applies to the entire DNS domain (e.g. "*.acme.com").Now when the user accesses any other servers in the "*.acme.com" domain, the browser will send the session cookie which will be silently validated by the new server without having to prompt the user to reauthenticate. There is a restriction in this type of session SSO however, in that neither the IP address nor the hostname (e.g. "mail") of the server can be used in the browser's URL

Terminating a Session

A session can be terminated a number of ways.

1. The user can physically logout.

2. The administrator can terminate the users session at anytime.

3. The session can reach its timeout or expire.

4. The maximum number of sessions for a user may be reached and one session will be terminated to allow for the new session.

When a session terminates, the server deletes the session and notifies any applications that have registered with the server for these notifications, thus preventing further access without manual authentication.

Password Synchronization

Some may mistakenly consider this the foundation of SSO. Password synchronization allows passwords to be consistent between all different servers, applications, and platforms. Authentication does occur within each of these, but it is now performed with the same credentials. This allows users to not have to manage multiple passwords and enhances security because users should not need to write down all their different passwords. Passwords synchronization can be either automatic, by using 3rd party software, or manual where the user performs the synchronization themselves.

Implementation

Implementing Password Synchronization if fairly simple. A mechanism is required to automatically change the password on all accounts associated with a user when they change one password. This implies that a database of all the accounts/resources which the user accesses with this one password has to be maintained. If the account name for the user is the same for each resource, this simplifies the process, but if each resource requires a unique ID for the user, the implementation increases in difficulty. The utility that changes each password has to have the intelligence to interact with the unique authentication engine of the protected resource. Keeping the passwords synchronized over multiple resources, means the password complexity can only be as strong as the weakest policy.

Strengths & Weaknesses

The strengths associated with Password Synchronization are:

• Reduces the strain and cost of having help desk personnel continuously helping users with their passwords
• Implementation of the technology is easy, quick and cost effective.
• With users only having to remember one password, they will be more inclined to use passwords with better quality complexity

The weaknesses associated with Password Synchronization are:

• Users still have to physically login to all of the resources they want to gain access to.
• If a would be intruder can guess one password, they would have the password to all the other resources.
• Password synchronization is often seen as a weakness in a security system.

Enrollment-based SSO

A user logging into a website may choose to have their credentials permanently remembered for that site. This is accomplished by creating an encrypted cookie on the user's machine for that web browser that contains the user's credentials. This cookie persists across different browser sessions and restarts of the machine, but will be set to expire after a set period. The next time the user accesses the website, the server recognizes the cookie, decrypts it to obtain the user's credentials and completely bypasses the login screen after validating them successfully.

Cross-domain SSO

Credentials may need to be transferred between different servers and domains, which is referred to as cross-domain single sign-on (CDSSO). By not relying on a master authentication server, CDSSO allows the user to easily be authenticated between separate secure domains, when requesting resources from each. This allows users to use SSO to easily move between different servers, creating a very user-friendly experience. In order to accomplish this, a secure user identity token is transferred from the first server to the next, identifying that the user has already been authenticated by the first server. The user is not required to login again, but instead the second server creates credentials based on the first server's token.

Reduced SSO

Reduced single sign-on is widely used for limiting the number of times a user will be required to enter in their credentials to access different applications. With critical applications, reduced SSO also offers a technique to make sure that a user is not signed on without a second factor of authentication, having been provided by the user. Second factor authentication can be implemented as a piece of hardware, like a smart card, challenge question, or even biometrics.

To achieve this successfully there are two sides to keep in mind, the level of IT security, and the user’s satisfaction with the process. If there is not a happy balance between the two then either the satisfaction for the user is low, or IT security may be compromised.

True Single Sign On (SSO) eliminates the need to repetitively enter your password every time you want to gain access to a protected resource. The downside to this is that should a user leave their client unlocked and unattended, anyone could gain access to everything on the PC. Reduced Sign On (RSO) addresses this issue by asking for additional credentials when attempting to access critical resources.

The following is a list of possible additional credentials:

• Challenge Question and Answer
• Digital Certificate
• Hardware Token
• Smart Card
• Biometrics

RSO allows the access of certain resources with one set of credentials, but requires additional credentials for other, more critical resources. Having the same password on all systems gives way to a complete breach should an intruder acquire the password. RSO puts additional or different passwords/authentication methods on servers and applications that have to be more securely controlled.

Some IT personnel believe that true SSO is not possible in real use cases. They prefer RSO for this reason. RSO has an advantage over SSO as it prevents access to everything should one password or authentication device be compromised., should SSO fail in a critical environment (ex. network failure) the results can be catastrophic as there will not be an alternate means of reaching critical data.

From the user’s perspective, RSO is not as convenient and easy to use as SSO. IT managers appreciate it for its increased security over SSO. Successfully using RSO requires just the right give and take to improve security without making it too cumbersome for the user to operate. The trick is to find the happy balance between security and convenience to keep the users and people responsible for security both satisfied.

Cookie-based SSO

Web based HTTP Cookies are employed to transport user credentials from browser to server without input from the user. Existing credentials on the client machine are gathered and encrypted before being stored in the cookie and sent to the destination server. The server receives the cookie, extracts and decrypts the credentials and validates them against the internal server directory of users.

SPNEGO-based SSO

There are instances when the client application and remote server do not know what types of authentication the other one supports. This is when SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) can be used to find out what authentication mechanisms are mutually available. Some of these mechanisms can include Kerberos and NTLM authentication.

NTLM-based SSO

It is possible for a user to prove they know their password without actually providing the password itself. NTLM achieves this using a challenge and response protocol that first determines what type of NTLM and encryption mechanisms the client and support mutually support, then cryptographically hashes the user's password and sends it to the server requiring authentication. Of the two types of NTLM authentication (interactive and noninteractive), only noninteractive NTLM provides SSO. It involves three systems: 1) a client attempting to request a resource, 2) the server hosting the resource and requiring authentication, and 3) a Windows domain controller that has knowledge of the user's password. If the server cannot access a domain controller, then NTLM SSO is not possible because the server has no way of validating the cryptographic hash of the end-user's password.

Kerberos-based SSO

Kerberos requires connectivity to a central Key Distribution Center (KDC). In Windows, each Active Directory domain controller acts as a KDC. Users authenticate themselves to services (e.g. web servers) by first authenticating to the KDC, then requesting encrypted service tickets from the KDC for the specific service they wish to use. Only the service (and the KDC) can decrypt the service ticket to get the user’s information. Because only the KDC could have created the service ticket, the service knows that the user must have also authenticated to the KDC so it can trust the user credentials in that ticket.

Form-filling SSO

Form-filling allows for the secure storage of information that is normally filled into a form. For users that repetitively fill out forms, especially for security access, this technology will remember/store all this information and secure it with a single password. To access the information the user only has to remember one password and the Form-filling technology can take care of filling in the forms.

Web-based SSO

Using an authentication mechanism web-based SSO occurs when the user has been authenticated, and credentials have been created that are then passed along to different web based applications. These web applications will then verify the credentials and allow SSO, creating a very streamlined access effect.

Biometric-based SSO

Existing biometric authentication can be combined with SSO technologies to further secure and simplify the life of the daily work force. Biometric authentication can include the use of fingerprints, retinal scans, facial scans, hand geometry, and even DNA. Although this has been somewhat controversial it is an up and coming strong method of authentication. Providing biometric evidence of your identity can unlock a local password database that contains the credentials for the requested resource.

Smart Card-based SSO

With smart card SSO the user is required to enter their smart card into a reader, which then allows them to sign-on to the desired application. The smart card information is then used to allow SSO to other applications that the user attempts to access. This means that the user will not be prompted for their credentials again, throughout their logon session. Removing the smart card from the reader will automatically lock the workstation and/or terminate the logon session.

Claims-based SSO

Claims (aka "assertions") are created by a claims issuer that is trusted by multiple parties. Claims are typically packaged into a digitally signed token that can be sent over the network using Security Assertion Markup Language (SAML). When a user wants to access a claims-aware application in either the local intranet or on the internet, the user's browser is redirected to authenticate automatically against his local directory structure (in Microsoft infrastructures this is done silently using Kerberos to the user's local Active Directory). This Kerberos information is then transformed by the claims issuer into potentially multiple SAML claims about the user and sent in the background back to the application. The application confirms that the claims came from the trusted issuer by verifying their digital signature. Once an application is made to be claims-aware, opening it up for access by other internal or external parties typically does not require any further changes to the application.

Screen Scraping

Screen scraping deals with recognizing and remembering the dialog boxes that prompt users for their credentials. The idea of "scraping" the fields and layout of these dialogs and automatically entering the user's credentials are the basis behind this SSO type. Once the information is scraped off of a log-in page and recorded, this information can then be stored in a credential vault where it will remain secure until the next time the dialog box is recognized. The credentials then will be automatically entered and submitted for the user.

Single Sign-on Systems:

Enterprise

Like most SSO systems enterprise single sign-on (E-SSO) systems are design for reducing the times that a user has to enter in their credentials to sign on to different applications. This is done using the technique of having passwords automatically filled in for the user, so that they do not have to enter them manually. ESSO solutions are usually software based, that move along with the user to make their access to applications a smooth one, staying away from more complex hardware based authentication methods. ESSO operates by storing multiple sets of credentials, which once remembered for each application, is not required for the user to know. In order to increase the level of security, after these credentials are established within the ESSO, the suggestion is made to increase the password strength rules and policies, to make the credentials stronger for each application, and harder to be guessed by an attacker.

Federated

Federated identity management is great for allowing enterprises and service providers to exchange information easily across various channels such as other divisions, partners, resellers and customers. This allows a single user profile to identify the user across multiple heterogeneous applications in the local infrastructure as well as to internet-based resources controlled by trusted third parties. It is important to understand that trusts must be established between companies in order for an application controlled by Company A to allow authentication from a user in Company B. In this scenario, the user only has to maintain a single user profile within Company B and the established trust allows it to be used to automatically login to the Company A application.