Enterprise Solutions

Single sign-on (SSO) is a property of access control of multiple, related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them. Single sign-off is the reverse property whereby a single action of signing out terminates access to multiple software systems.

As different applications and resources support different authentication mechanisms, single sign-on has to internally translate to and store different credentials compared to what is used for initial authentication.

Benefits

Benefits include:

  • Reduces phishing success, because users are not trained to enter password everywhere without thinking.
  • Reducing password fatigue from different user name and password combinations.
  • Reducing time spent re-entering passwords for the same identity
  • Can support conventional authentication such as Windows credentials (i.e., username/password)
  • Reducing IT costs due to lower number of IT help desk calls about passwords
  • Security on all levels of entry/exit/access to systems without the inconvenience of re-prompting users
  • Centralized reporting for compliance adherence.

SSO uses centralized authentication servers that all other applications and systems utilize for authentication purposes, and combines this with techniques to ensure that users do not actively have to enter their credentials more than once.

Criticisms

The term enterprise reduced sign-on is preferred by some authors who believe single sign-on to be impossible in real use cases.

As single sign-on provides access to many resources once the user is initially authenticated ("keys to the castle"), it increases the negative impact in case the credentials are available to other persons and misused. Therefore, single sign-on requires an increased focus on the protection of the user credentials, and should ideally be combined with strong authentication methods like smart cards and one-time password tokens.

Single sign-on also makes the authentication systems highly critical, their failure or an inability to reach them (such as in a network failure) can result in denying access to all systems unified under the SSO. This can make SSO undesirable for systems to which access has to be guaranteed at all times, such as security or plant-floor systems.

 

Common Single Sign-On Configurations

Kerberos based

  • Initial sign-on prompts the user for credentials, and gets a Kerberos ticket-granting ticket (TGT).
  • Additional software applications requiring authentication, such as email clients, wikis, revision control systems, etc., use the ticket-granting ticket to acquire service tickets, proving the user's identity to the mailserver / wiki server / etc. without prompting the user to re-enter credentials.

Windows environment - Windows login fetches TGT. Active Directory-aware apps fetch service tickets, so user is not prompted to re-authenticate.

UNIX/Linux environment - Login via Kerberos PAM modules fetches TGT. Kerberized client applications such as Evolution, Firefox, and SVN use service tickets, so user is not prompted to re-authenticate.

Smart card based

Initial sign on prompts the user for the smart card. Additional software applications also use the smart card, without prompting the user to re-enter credentials. Smart card-based single sign-on can either use certificates or passwords stored on the smart card.

OTP Token

Also referred to as one -time password token. Two-factor authentication with OTP tokens follows industry best practices for authenticating users. This OTP token method is more secure and effective at prohibiting unauthorized access than other authentication methods.

Integrated Windows Authentication

Integrated Windows Authentication is a term associated with Microsoft products and refers to the SPNEGO, Kerberos, and NTLMSSP authentication protocols with respect to SSPI functionality introduced with Microsoft Windows 2000 and included with later Windows NT-based operating systems. The term is used more commonly for the automatically authenticated connections between Microsoft Internet Information Services and Internet Explorer. Cross-platform Active Directory integration vendors have extended the Integrated Windows Authentication paradigm to UNIX, Linux and Mac systems.

Shared authentication schemes which are not single sign-on

Single sign on requires that users literally sign in once to establish their credentials. Systems which require the user to log in multiple times to the same identity are inherently not single sign on. For example, an environment where users are prompted to log in to their desktop, then log in to their email using the same credentials, is not single sign on.

Enterprise single sign-on

Enterprise single sign-on (E-SSO) systems are designed to minimize the number of times that a user must type their ID and password to sign into multiple applications. The E-SSO solution automatically logs users in, and acts as a password-filler where automatic login is not possible.

Some E-SSO solutions focus on delivering quick return on investment and shy away from requiring complex infrastructure hardware additions. These solutions are generally software-based agents which roam with the user and automate the process of login and password change for the desired applications (Win/Java/Ajax/Web/Terminal Emulator). The benefit of this approach is that users can have any username/password for the target systems/applications because from the E-SSO agents perspective they are all just 'credentials' to store. Given that user credentials may be cached locally (and sync'd to a central repository) the use of strong encryption as well as reliable and viable key recovery options are suggested for the chosen E-SSO technology.

Ideally, there is no need for the users to actually have a first hand understanding of their assigned credential(s) for end applications after implementation of E-SSO, and as an upside once users have confidence in this way of thinking application owners are encouraged to increase password length and complexity such that the user could not easily remember the password on their own.

There is also a significant security upside with client side E-SSO solutions. Given that the user's credentials are now stored in a very secure cryptographically locked store and that the users themselves no longer know (or care to know) the applications credentials, it's possible to 'release' (logon with) certain credentials based on a defined 'authentication grade'. Two factor authentication systems such as smart cards or biometrics can be linked to different authentication grades. A user might for example have 10 sets of credentials in their encrypted store, for 10 different applications. Applications 1 through 6 might simply require that the user has shown to have successfully logged in to the primary domain (i.e. Windows Active Directory, etc) but when the E-SSO client goes to log on the user to applications 7-10 it might check for the insertion/presence of a smart card with valid user keys on it. By doing this the enterprise has effectively implemented two factor authentication but have not had to deal with the challenges of back-end infrastructure additions/application modifications, etc.

With client-side E-SSO solutions enterprises can very easily transition from a regime where passwords are easily brute forced and authentication is single factor to a scenario where high yield applications are now two factor authentication access controlled, passwords are complex and users don't know them, hence hackers cannot effectively brute force applications with dictionary or rainbow tables.

General requirements for E-SSO

  • The solution needs to be highly available.
  • The solution needs to provide interfaces for backup, 24x7 monitoring and operations, etc.
  • The solution needs to be able to scale to many thousands of users accessing enterprise software.
  • The solution should be able to support the company-internal standards defined for efficient operations and integration without problems (e.g., directory server standards, authentication standards, etc.).
  • The solution should be able to easily integrate related IT solutions, for example existing identity management solutions, security event management solutions, application management solutions, or desktop software distribution solutions.

 



Copyright © 2010-2013 IdentyTech Ltd-Biometric Solutions | Designed By Qwert789