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 for each of them. Conversely, Single sign-off is the property whereby a single action of signing out terminates access to multiple software systems.
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.
Benefits
Benefits of using single sign-on include:
• Reducing password fatigue from different user name and password combinations
• Reducing time spent re-entering passwords for the same identity
• Reducing IT costs due to lower number of IT help desk calls about passwords
Common Configurations
Below are the common configuration methods, which are being used for single sign-on authentication:
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, and SVN use service tickets, so user is not prompted to re-authenticate.
Other common configuration methods used for SSO authentication are:
• Smart card Based
• OTP token
• Integrated Windows Authentication
• Security Assertion Markup Language (SAML)
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 into their desktop, then log into their email using the same credentials, is not single sign-on.
References:
http://en.wikipedia.org/wiki/Single_sign-on
http://www.opengroup.org/security/sso/sso_intro.htm
Also, the following links provide information about a security study (made in March, 2012) of some Commercially Deployed Single-Sign-On Web Services, their flaws and resolutions:
http://research.microsoft.com/apps/pubs/default.aspx?id=160659
http://openid.net/2012/03/14/vulnerability-report-data-confusion/
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.
Benefits
Benefits of using single sign-on include:
• Reducing password fatigue from different user name and password combinations
• Reducing time spent re-entering passwords for the same identity
• Reducing IT costs due to lower number of IT help desk calls about passwords
Common Configurations
Below are the common configuration methods, which are being used for single sign-on authentication:
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, and SVN use service tickets, so user is not prompted to re-authenticate.
Other common configuration methods used for SSO authentication are:
• Smart card Based
• OTP token
• Integrated Windows Authentication
• Security Assertion Markup Language (SAML)
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 into their desktop, then log into their email using the same credentials, is not single sign-on.
References:
http://en.wikipedia.org/wiki/Single_sign-on
http://www.opengroup.org/security/sso/sso_intro.htm
Also, the following links provide information about a security study (made in March, 2012) of some Commercially Deployed Single-Sign-On Web Services, their flaws and resolutions:
http://research.microsoft.com/apps/pubs/default.aspx?id=160659
http://openid.net/2012/03/14/vulnerability-report-data-confusion/
No comments:
Post a Comment