Single sign-on

Latest revision as of 14:13, 24 November 2010

Purpose of the page

One of the result of the community web-site meeting was, that a single sign-on (SSO) concept is the basic requirement for all the different services, which should run on MeeGo.com. There are many different possibilities how to realise that, with as many pros and cons. Purpose of this wiki-page is to gather the information together and to have a meeting soon based on that information.

General requirements

Here are general requirements, which the SSO solution should meet. Please feel free to modify the list:

• User identity and credentials are consistent across the sites and systems
• Once a user is authenticated to one system the user should not need to authenticate to other systems

In user story terms? In priority order?

• As a user
  • I'd like to use the same username and password to access any meego or affiliated sites
  • When I change my details (including my password) I want that change to be respected by all affiliated sites
  • Once I've entered my credentials I do not want to have to enter them again when I visit an affiliated site
  • Once I logout from a site, I am logged out from any affiliated sites

Could some sites be fully integrated (support all stories) and others partly (only 1+2)

Technical Criteria

• Support for multiple programming languages
• Support or easy adoption for MeeGo services:
  • CMS-system (Drupal)
  • Wiki (MediaWiki)
  • Issue tracker (Bugzilla)
  • Forum (vBulletin)
  • News (Midgard)
  • Build service (OBS)
• Abstraction from the authentication method (Database, OpenID, LDAP, etc)
• User-data management (no must, but nice to have)
• Already used in big projects

Solutions

• CENTRAL AUTHENTICATION SERVICE (CAS) CAS provides a central system for applications and handles the user authentication for them. Technically CAS is a Java web application, which supports Tomcat to set it up. The management of the user credentials is not handled within the service. Commonly used authentication methods are supported, like LDAP, databases via JDBC, JAAS etc. Further, CAS supports different programming languages (PHP, Perl, Java) and provides clients for it. For the mediawiki is directly a plugin available. It supports besides its own authentication protocol OpenID and SAML. The provided example show, that it is pretty straight forward to add an application to the service.
• JOSSO: This service is a Java-based implementation of a centralized authentication system. It runs on Java application servers like Tomcat or JBoss. The user data management is in JOSSO can be as well as in the CAS case be implemented with LDAP or an additional database. The drawback is the support of client agents. It is possible though to use the support of Perl through the Apache and its modules but direct client libraries are only supported for Java and PHP. OpenID and SAML can be used as authentication protocols as well.
• OpenSSO Java based authentication System, which is supported by Sun. The service runs on a Java application server, and supports as well as the previous systems the management of the user identity data in a database (JDBC) or integrated by LDAP. OppenSSO is Java-based, but supports as well other clients. The support for further clients seems to be not really in the focus of OpenSSO. The client SDK for PHP is for example under construction. OpenID and SAML extensions are available and the service is extensible with those.
• Shibboleth is another security ticket -based authentication protocol that is fairly common in the university world. It also has the benefit of providing a federated identity and authentication network where meego.com could also trust maemo.org user authentication and vice versa. It is slightly heavier to implement than CAS but is likely to provide security benefits. We have some experience with Shibboleth from various university web projects. Another benefit is that Shibboleth can be used as an Apache authentication module meaning that any web tool that supports Apache-level authentication can authenticate via it out-of-the-box. (http://lists.meego.com/pipermail/meego-community/2010-February/000102.html)
  • http://en.wikipedia.org/wiki/Shibboleth_(Internet2)
  • https://spaces.internet2.edu/display/SHIB2/UnderstandingShibboleth
• OpenID is an open authentication protocol, which allows a user to use an account of a OpenID provider of his/her choice and use it to login on every service, which supports the protocol. The idea bases simply on a unique id, which is provided to the user and which identifies the OpenID provider. The typical structure is 'username.openid_provider_url'. On the service, where the user wants to login, the OpenID has to be entered and after that, the user is redirected to the OpenID login page of the provider. To provide misusage the user has to agree use the OpenID provider to sign-on the service. Finally a redirect to the original service will take place. The service application validates the incoming data with the OpenID provider and the user is logged in.
• Lemonldap::NG is a modular Web-SSO based on Apache::Session modules. It simplifies the build of a protected area with a few changes in the application. It manages both authentication and authorization and provides headers for accounting.
• OAuth "An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications". Released/backed by Google/Twitter. There appear to be multiple client implementations
• Drupal Module A new Drupal module can be created for each system to handle user replication as well as single-sign on, direct from the standard Drupal login page. This is the solution being used to link Drupal (meego.com) and vBulletin (forum.meego.com) via the module Drupal vB.
• SAML ...

Links

• Initial post of Henri Bergius
• SSO in Maemo.org