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. This information will be posted and constantly added to our College of Authentication webpage.
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, by leveraging those credentials when navigating to other resources during your session that will also require you to verify your identity.
Session-based SSO
A basic user session is created before single sign-on occurs, where a session token is then created and verified, authenticating the user. From then on SSO is accomplished by presenting the session token as authentication. The verification is done using a policy agent to verify the token and grant access to the user.
Password Synchronization
This, some may consider, is the foundation of SSO. Password synchronization allows passwords to be coordinated between all different servers, applications, and platforms. Authentication does occur within each of these, but it is now done behind the scenes. This allows users to not have to manage multiple passwords, and enhances security. Password synchronization is usually either transparent, such as using Active Directory, or web-based, where the user uses a browser to manage their passwords.
Enrollment-based SSO
An internet user sometimes enters a domain through a browser without having to access the home domain. When this happens the home domain will actually send out a Domain Identity Cookie (DIDC) to request enrollment from the user’s browser, which is actually redirected to an affiliated server within an e-community. The affiliated server processes and sends back an enrollment confirmation to the user’s browser, which is redirected to the home domain server. The home domain server will then mark the DIDC as being verified with a symbol, indicating successful enrollment. They can be done many times to achieve SSO within many parts of the e-community.
Cross-domain SSO
Often credentials 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 different resources from each. This allows users to use SSO to easily move between different servers, creating a very scalable network architecture. 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 create any login credentials, but instead the second server creates credentials off of the token information.
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.
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 that occur when trying to authenticate, when the client application and remote server do not know what types of authentication the other one has. This is when SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) uses a protocol to find out what GSSAPI mechanisms are available to it. Some of these mechanisms can include NTLM and Kerberos.
NTLM-based SSO
The credentials that are used for NTLM authentication are different in the sense that they contain a domain name, user name, and hash of the user’s password. In order for the user to authenticate, and without having their password transmitted, NTLM uses a challenge question and response functionality, which will allow a determination to be made if the system requesting the credentials should be allowed access. There are two types of NTLM authentication: interactive, and noninteractive. The interactive type of NTLM authentication requires usually two systems, a client system, and a domain controller. Noninteractive requires three systems, a client, server, and a domain controller.
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 (WAM)
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 existing 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 a up and coming strong method of authentication and proving a user's identity.
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.
OTP Token SSO
One-time passwords (OTP) are designed to remove the threats associated with static passwords, as well as establish a form of two-factor authentication. By creating a password that is only good for one login or transaction, these types of passwords are not as susceptible to replay attacks. Once a OTP token has been created this can now be used to verify the user to other applications they may be attempting to access.
Screen Scraping
Screen scraping is related to taking a visual image of the screen and obtaining the information off of it. The idea of scraping the information off and putting it into a format that is more usable is 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 form where other applications, servers, and platforms can access it to verify the user’s credentials.
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 partners, resellers, other divisions, and many other groups. This allows the identity information to be stored in central identity groups, and then have a copy of that information sent when authentication is required to the requestor. This smoothes the process of collaboration and removes many roadblocks when working with multiple groups. Not being limited to just end-user or browser applications, federated identity management allows for direct secure access to be provided to external organizations. Usually activity is controlled within the form of a hub or spoke, such as service provider hub, identity provider hub, or even a multi cross-domain hub as well.
|
