From WhyNotWiki

Single sign-on  edit   (Category  edit)

http://en.wikipedia.org/wiki/Single_sign-on

http://www.authenticationworld.com/Single-Sign-On-Authentication/. Retrieved on 2007-05-11 11:18.

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.

Contents 1 Federated identity 1.1 Background 1.2 Identity Federation 2 Why it's a good thing 3 Single sign-on in use at colleges 3.1 How do I obtain the user's name, status, etc 3.2 Why should I change my existing service to use CAS 3.3 4 Specific technologies/platforms/protocols 4.1 JA-SIG Central Authentication Service (CAS) 4.2 RubyCAS client 4.3 Enterprise Sign-On Engine (ESOE / E-SSO) 4.4 SAML Security Assertion Markup Language (SAML) 4.5 Shibboleth

[edit] Federated identity

http://en.wikipedia.org/wiki/Federated_identity. Retrieved on 2007-05-11 11:18.

In information technology, federated identity has two general meanings:

• The virtual reunion, or assembled identity, of a person's user information (or principal), stored across multiple distinct identity management systems. Data is joined together by use of the common token, usually the user name.
• The process of a user's authentication across multiple IT systems or even organizations.

For example, a traveler could be a flight passenger as well as a hotel guest. If the airline and the hotel use a federated identity management system, this means that they have a contracted mutual trust in each other's authentication of the user. The traveler could identify themselves once as a customer for booking the flight and this identity can be carried over to be used for the reservation of a hotel room.

[edit] Background

Centralized identity management solutions were created to help deal with user and data security where the user and the systems they accessed were within the same network -- or at least the same ‘domain of control’. Increasingly however, users are accessing external systems which are fundamentally outside of their domain of control, and external users are accessing internal systems. The increasingly common separation of user from the systems requiring access is an inevitable by-product of the decentralization brought about by the integration of the Internet into every aspect of both personal and business life. Evolving identity management challenges, and especially the challenges associated with cross-company, cross-domain issues, has given rise to a new approach of identity management, known now as ‘federated identity management.’

[edit] Identity Federation

Federated identity, or the ‘federation’ of identity, describes the technologies, standards and use-cases which serve to enable the portability of identity information across otherwise autonomous security domains. The ultimate goal of identity federation is to enable users of one domain to securely access data or systems of another domain seamlessly, and without the need for completely redundant user administration. Identity federation comes in many flavors, including ‘user-controlled’ or ‘user-centric’ scenarios, as well as enterprise controlled or B2B scenarios.

Federation is enabled through the use of open industry standards and/or openly published specifications, such that multiple parties can achieve interoperability for common use cases. Typical use-cases involve things such as cross-domain, web-based single sign-on, cross-domain user account provisioning, cross-domain entitlement management and cross-domain user attribute exchange.

Use of identity federation standards can reduce cost by eliminating the need to scale one-off or proprietary solutions. It can increase security and lower risk by enabling an organization to identify and authenticate a user once, and then use that identity information across multiple systems, including external partner websites. It can improve privacy compliance by allowing the user to control what information is shared, or by limited the amount of information shared. And lastly, it can drastically improve the end-user experience by eliminating the need for new account registration through automatic ‘federated provisioning’ or the need to redundantly login through cross-domain single sign-on. Leading enterprises around the world have deployed identity federation to get closer with partners, improve customer service, accelerate execution of business partnerships and alliances, cut cost and complexity of integrating outsourced services, and free themselves from vendor lock-in. End-users and consumer focused web sites are now beginning to engage in identity federation through the adoption of OpenID, which is an open source specification for enabling federation use-cases.

[edit] Why it's a good thing

Password fatigue - Wikipedia, the free encyclopedia (http://en.wikipedia.org/wiki/Password_fatigue). Retrieved on 2007-05-11 11:18.

Password fatigue describes the syndrome where people are required to remember an excessive number of passwords as part of their daily living.

The increasing prominence of information technology and the Internet in employment, finance, recreation and other aspects of people's lives, and the ensuing introduction of secure transaction technology, has led to people accumulating a proliferation of accounts and passwords. According to British online-security consultant NTA Monitor the typical intensive computer user has 21 accounts that require a password.

Aside from contributing to stress password fatigue may encourage people to adopt risky strategies that reduce the security of their information, putting them at risk of identity fraud. For example, an account holder might use the same password for several different accounts, deliberately choose easy to remember passwords that are vulnerable to cracking, or alternatively create written records of their passwords.

Single sign-on software can help mitigate this problem by only requiring users to remember one password to an application that in turn will automatically give access to several other accounts.

[edit] Single sign-on in use at colleges

Single sign-on in use at colleges edit

[edit] Specific technologies/platforms/protocols

[edit] JA-SIG Central Authentication Service (CAS)

Homepage:	http://en.wikipedia.org/wiki/Central_Authentication_Service
Description:	an open single sign-on service (originally developed by Yale University) that allows web applications the ability to defer all authentication to a trusted central server or servers. Numerous clients are freely available, including clients for Java, .Net, PHP, Perl, Apache, uPortal, Liferay and others.

[edit] RubyCAS client

Homepage:	http://rubycas-client.rubyforge.org/
Project/Development:	http://rubyforge.org/projects/rubycas-client
As listed in other directories:	http://code.google.com/p/rubycas-client/ http://www.ohloh.net/projects/3756
Implementation language:	Ruby

Error on call to Template:cite web: Parameter url must be specified. Retrieved on 2007-05-11 11:18.

CAS provides a solid and secure single sign on solution for web-based applications. When a user logs on to your CAS-enabled website, the CAS client checks with the CAS server to see if the user has been centrally authenticated. If not, the user is redirected to your CAS server‘s web-based login page where they enter their credentials, and upon successful authentication are redirected back to your client web application. If the user has been previously authenticated with the CAS server (with their "ticket" being held as a session cookie), they are transparently allowed to go about their business.

This client requires a CAS server to talk to. You can obtain a Java implementation of such a server as well as more info about the CAS protocol here: www.ja-sig.org/products/cas

This CAS client library is designed to work easily with Rails, but can of course be used elsewhere.

[edit] Enterprise Sign-On Engine (ESOE / E-SSO)

http://www.esoeproject.org/. Retrieved on 2007-05-11 11:18.

The Enterprise Sign On Engine (ESOE) is an advanced system which allows an enterprise to meet it's individual goals for integrated identity management, single sign on, authorization, federation and accountability for resource access in a very extensible manner.

The ESOE is built using the OASIS SAML 2.0 specification, and the ESOE's powerful authorization engine is built around a reduced version of the OASIS XACML 2.0 standard which we have called Lightweight eXtensible Authorization Control Markup Language or "LXACML".

The ESOE can integrate identity from unlimited repositories, automatically create sessions for users whom are logged into Active Directory (true single sign on), provide for centralized authorization policy management and natively federate with technologies such as Shibboleth and OpenID.

We hope you'll find the ESOE a good choice for your needs amongst the wide variety of SSO solutions that are available, both from commercial providers and other open source projects. Of course if you're already using an SSO solution, there is a pretty good chance the ESOE can interact with it, allowing you to use the enhanced capabilities of the ESOE without needing to replace everything you already have.

Being heavily standards based, all your existing identity infrastructure such as LDAP compliant directories, databases and even flat files are only a plugin away. The ESOE is designed to fit around your environment, not have your environment change to fit it.

[edit] SAML Security Assertion Markup Language (SAML)

http://en.wikipedia.org/wiki/Single_sign-on. Retrieved on 2007-05-11 11:18.

[...] is an XML standard for exchanging authentication and authorization data between security domains, that is, between an identity provider and a service provider. SAML is a product of the OASIS Security Services Technical Committee.

[edit] Shibboleth

http://en.wikipedia.org/wiki/Single_sign-on. Retrieved on 2007-05-11 11:18.

a standards-based, open source middleware software which provides Web Single SignOn (SSO) across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner.