Single sign-on

Single sign-on (SSO) is a property of access control of multiple related, but independent software systems. With this property a user logs in with a single ID and password to gain access to a connected system or systems without using different usernames or passwords, or in some configurations seamlessly sign on at each system. This is typically accomplished using the Lightweight Directory Access Protocol (LDAP) and stored LDAP databases on (directory) servers.[1] A simple version of single sign-on can be achieved over IP networks using cookies but only if the sites share a common DNS parent domain.[2]

For clarity it is best to refer to systems requiring authentication for each application but using the same credentials from a directory server as Directory Server Authentication and systems where a single authentication provides access to multiple applications by passing the authentication token seamlessly to configured applications as Single Sign-On.

Conversely, single sign-off is the 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 must internally store the credentials used for initial authentication and translate them to the credentials required for the different mechanisms.

Other shared authentication schemes include OAuth, OpenID, OpenID Connect and Facebook Connect. However, these authentication schemes require the user to enter their login credentials each time they access a different site or application so they are not to be confused with SSO.

To be precise, OAuth is not strictly an authentication scheme but an authorization protocol: it provides a way for the users to grant access on their own behalf to websites or applications to other websites or applications using some access keys. The main purpose of the protocol is to exchange the access credentials required for the authentication and not the authentication itself.

Benefits

Benefits of using single sign-on include:

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

Criticisms

The term reduced sign-on (RSO) has been used by some to reflect the fact that single sign-on is impractical in addressing the need for different levels of secure access in the enterprise, and as such more than one authentication server may be necessary.[4]

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 people 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.[4]

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 be configured with session failover capabilities in order to maintain the system operation.[5] Nonetheless, the risk of system failure may make single sign-on undesirable for systems to which access must be guaranteed at all times, such as security or plant-floor systems.

Furthermore, the use of single sign-on techniques utilizing social networking services such as Facebook may render third party websites unusable within libraries, schools, or workplaces that block social media sites for productivity reasons. It can also cause difficulties in countries with active censorship regimes, such as China and its "Golden Shield Project," where the third party website may not be actively censored, but is effectively blocked if a user's social login is blocked.[6][7]

Security

In March, 2012, a research paper[8] reported an extensive study on the security of social login mechanisms. The authors found 8 serious logic flaws in high-profile ID providers and relying party websites, such as OpenID (including Google ID and PayPal Access), Facebook, Janrain, Freelancer, FarmVille, and Sears.com. Because the researchers informed ID providers and relying party websites prior to public announcement of the discovery of the flaws, the vulnerabilities were corrected, and there have been no security breaches reported.[9]

In May 2014, a vulnerability named Covert Redirect was disclosed.[10] It was first reported "Covert Redirect Vulnerability Related to OAuth 2.0 and OpenID" by its discoverer Wang Jing, a Mathematical PhD student from Nanyang Technological University, Singapore.[11][12][13] In fact, almost all Single sign-on protocols are affected. Covert Redirect takes advantage of third-party clients susceptible to an XSS or Open Redirect.[14]

Common configurations

Kerberos based

Windows environment - Windows login fetches TGT. Active Directory-aware applications fetch service tickets, so the 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 the 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.

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 most commonly used to refer to 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.

Security Assertion Markup Language

Security Assertion Markup Language (SAML) is an XML-based solution for exchanging user security information between an enterprise and a service provider. It supports W3C XML encryption and service provider initiated web browser single sign-on exchanges. A user wielding a user agent (usually a web browser) is called the subject in the SAML-based single sign-on. The user requests a web resource protected by a SAML service provider. The service provider, wishing to know the identity of the requesting user, issues an authentication request to a SAML identity provider through the user agent. The identity provider is the one that provides the user credentials. The service provider trusts the user information from the identity provider to provide access to its services or resources.

Emerging configurations

Mobile devices as access controllers

A newer variation of single sign-on authentication has been developed using mobile devices as access controllers. Users' mobile devices can be used to automatically log them onto multiple systems, such as building access control systems and computer systems, through the use of authentication methods which include OpenID Connect and SAML,[15] in conjunction with an X.509 ITU-T cryptography certificate used to identify the mobile device to an access server.

See also

References

  1. ↑ "SSO and LDAP Authentication". Authenticationworld.com. Retrieved 2014-05-23.
  2. ↑ "OpenID versus Single-Sign-On Server". alleged.org.uk. 2007-08-13. Retrieved 2014-05-23.
  3. ↑ "Benefits of SSO". University of Geulph. Retrieved 2014-05-23.
  4. 1 2 "Single Sign On Authentication". Authenticationworld.com. Retrieved 2013-05-28.
  5. ↑ "Sun GlassFish Enterprise Server v2.1.1 High Availability Administration Guide". Oracle.com. Retrieved 2013-05-28.
  6. ↑ Laurenson, Lydia (3 May 2014). "The Censorship Effect". TechCrunch. Retrieved 27 February 2015.
  7. ↑ Chester, Ken (12 August 2013). "Censorship, external authentication, and other social media lessons from China's Great Firewall". Tech in Asia. Retrieved 9 March 2016.
  8. ↑ Rui Wang; Shuo Chen & XiaoFeng Wang. "Signing Me onto Your Accounts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services".
  9. ↑ "OpenID: Vulnerability report, Data confusion" - OpenID Foundation, March 14, 2012
  10. ↑ "Facebook, Google Users Threatened by New Security Flaw". Tom's Guide. 2 May 2014. Retrieved 11 November 2014.
  11. ↑ "Covert Redirect Vulnerability Related to OAuth 2.0 and OpenID". Tetraph. 1 May 2014. Retrieved 10 November 2014.
  12. ↑ "Math student detects OAuth, OpenID security vulnerability". Tech Xplore. 3 May 2014. Retrieved 10 November 2014.
  13. ↑ "Facebook, Google Users Threatened by New Security Flaw". Yahoo. 2 May 2014. Retrieved 10 November 2014.
  14. ↑ "Covert Redirect Flaw in OAuth is Not the Next Heartbleed". Symantec. 3 May 2014. Retrieved 10 November 2014.
  15. ↑ "MicroStrategy's office of the future includes mobile identity and cybersecurity". Washington Post. 2014-04-14. Retrieved 2014-03-30.

External links

This article is issued from Wikipedia - version of the 11/30/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.