Single Sign-on(SSO).

According to wiki.

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 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 have to actively enter their credentials more than once.

SSO users need not remember so many passwords to login to different systems or applications.

The term enterprise reduced sign-on is preferred by some authors^[who?] 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; a loss of their availability can result in denial of access to all systems unified under the SSO. SSO can thus be undesirable for systems to which access must 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 applications 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, andSVN 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 ^[1] follows industry best practices for authenticating users.^[2] This OTP token method is more secure and effective at prohibiting unauthorized access than other authentication methods.^[3]

Integrated Windows Authentication

Integrated Windows Authentication is a term associated with Microsoft products and refers to the SPNEGO, Kerberos, and NTLMSSPauthentication 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.


According to other analysis.

What Is Single Sign On?

Single Sign On (SSO) (also known as Enterprise Single Sign On or "ESSO") is the ability for a user to enter the same id and password to logon to multiple applications within an enterprise. As passwords are the least secure authentication mechanism, single sign on has now become known as reduced sign on (RSO) since more than one type of authentication mechanism is used according to enterprise risk models.

For example, in an enterprise using SSO software, the user logs on with their id and password. This gains them access to low risk information and multiple applications such as the enterprise portal. However, when the user tries to access higher risk applications and information, like a payroll system, the single sign on software requires them to use a stronger form of authentication. This may include digital certificates, security tokens, smart cards, biometrics or combinations thereof.

Single sign on can also take place between enterprises using federated authentication. For example, a business partner's employee may successfully log on to their enterprise system. When they click on a link to your enterprise's application, the business partner's single sign on system will provide a security assertion token to your enterprise using a protocol like SAML, Liberty Alliance, WS Federation or Shibboleth. Your enterprise's SSO software receives the token, checks it, and then allows the business partner's employee to access your enterprise application without having to sign on.

Single sign on federated authentication also works with your employees. For example, an employee who is trying to access your outsourced benefits supplier to update their benefits information would click on the benefits link on your intranet. Your enterprise's single sign on software would then send a security assertion token to the benefits supplier. The benefits supplier's SSO system would then take the token, check it and grant access to your employee without making them sign on.

Single Sign On Benefits

Single sign on benefits are:

• Ability to enforce uniform enterprise authentication and/or authorization policies across the enterprise
• End to end user audit sessions to improve security reporting and auditing
• Removes application developers from having to understand and implement identity security in their applications
• Usually results in significant password help desk cost savings

Since the internet is stateless, this means that the single sign on software must check every request by the user's browser to see if there is an authentication policy pertaining to the resource or application the user is trying to access. In a medium to large enterprise, this means that every time the user clicks on a different URL, there is traffic between the user's browser, the web or application servers and the security server. This traffic can become large and cumbersome from a performance perspective. Therefore, most modern single sign on systems use LDAP (Lightweight Directory Access Protocol) directories to store the authentication and authorization policies. The LDAP directories are made for high performance lookups thus addressing the high traffic load. Further, the LDAP directories are often the source for the single sign on system to authenticate against.

Single sign on systems in medium to large enterprises can become a single point of enterprise failure if not properly designed. If the single sign on system goes down but the applications remain up, no user can access any resource or application protected by the SSO system. Many enterprises have experienced this painful condition resulting in productivity loss. Therefore, it is essential that your enterprise single sign on system have a good and well tested failover and disaster recovery design.

Finally, single sign on systems in medium to large enterprises requires good identity data governance. Enterprise security features being offered by the single sign on system is only as good as the underlying identity data. Thus it is critical that all enterprise identity data have good, quick business processes that pick up on any change to the identity such as new identity creation, identity termination or role changes. Without this, enterprise SSO systems are vulnerable to creating enterprise security holes.