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.
Here are general requirements, which the SSO solution should meet. Please feel free to modify the list:
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 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)
OPENID 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.