Like a diamond, Single Sign-on (SSO) is multifaceted. SSO has multiple ways to launch for a seamless, user login. The last two blog entries expounded on a SAML-based SSO, but below are some other implementations used for SSO.
Cookie-based SSO: Cookie-based SSO works by using web based HTTP cookies to transport user credentials from browser to server without input from the user.
Kerberos-based SSO: Kerberos enables a user to log into their Windows domain account and then receive SSO to their internal applications.
Screen Scraping: Using this type of SSO, your credentials are remembered through “scraping” the fields and layout of the HTML login forms that prompt you for your credentials. Once scraped, the credentials are then automatically entered by the browser or browser add-on.
Claims-based SSO: A claims issuer creates one-time use tokens that contain one or more identity claims (aka “assertions”). The claims issuer digitally signs the token to prevent tampering and the end point servers are configured to trust the issuer. The identity claims are then used to establish the user’s identity or access rights..
Smart Card-based SSO: The smart card is swiped in a smart card reader, the user enters a PIN code to unlock the contents and in turn, the user gains access to applications based on the information from the smart card.
Biometric-based SSO: By combining SSO and existing biometric authentication (fingerprints, retinal scans, facial scans, hand geometry, etc.), biometric-based SSO goes further to create stronger security and a simplified workday but still has problems with accuracy and false positives.
Form-filling SSO: Form-filling stores information for users that repetitively fill out forms; using SSO with form-filling, the user only needs to remember one password and the form-filling technology will take care of filling in the forms.
NTLM-based SSO: NTLM uses a challenge and response protocol that allows the user to prove they know their password without actually providing the password itself to the server.
SPNEGO-based SSO: Sometimes 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. These can typically result in Kerberos or NTLM authentication being performed.
Reduced SSO: This is not a “fat free” version of SSO, but rather, reduced SSO limits the number of times a user will be required to provide their credentials to access different applications.
Enrollment-based SSO: Once a user’s credentials are permanently remembered in an encrypted cookie, the server recognizes the cookie, decrypts it to obtain the user’s credentials, and completely by-passes the login screen after validating the user.
Session-based SSO: Session-based SSO is accomplished when a session token is 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. When this cookie is persisted across restarts of the browser, they are not asked to manually login when visiting the site for a constrained period of time; this is similar to Enrollment-based SSO.
True SSO: After providing your credentials, True SSO leverages the credentials while you navigate to other sources eliminating the need to to verify your identity for each source.
PortalGuard offers multifaceted, SSO solutions for an integrated login experience.