Task:Single sign-on

Image:Ambox_notice.png
 This article does not provide enough information, and needs to be expanded to more fully cover the topic.
Please see the talk page for discussion.


Contents

[edit] Introduction

The following gives an overview of the first draft of a Single Sign-on (SSO) concept for the maemo.org components, as they exist at the moment. The components are:

  • Midgard – Content Management System (PHP and C/Java)
  • Bugzilla – Bugtracker tool (Perl)
  • Mediawiki – Wiki software application (PHP)
  • Gforge – Project management system (PHP)

The situation right now requires from every user for every of the listed components a separate account with a username/password combination to access the different services. Goal of this proposal is a solution, which provides a SSO concept for all those application together, and which prevents the user from creating a new account. The document only gives an overview of the different possible options and requires some basic understanding of SSO concepts. It is not meant being a tutorial, but rather to give a proposal for the existing architecture. Further information can be found by following the added links. Feel free to comment and add information, where you think that it is helpful.

[edit] Requirements

As the basic infrastructure is already given by the tools, which are already in use, the new components have to fit into it and support them. The basic requirements for the possible solutions are:

  1. Additional components should be Open Source solutions
  2. Existing tools have to be supported
  3. Prevent basic changes in existing infrastructure
  4. Improvement in user experience should worth the additional amount of work
  5. Should base on standard technologies

Based on the now defined goals and requirements possible solutions can be discussed. The focus should be clearly on the enhancements in the usability for the user. The first question is, which type of SSO concept is most adaptable to the given scenario. The first possibility would be to integrate a authentication server, which handles all the user related information. Secondly open standards like OpenID or SAML could provide an application-focused authentication. A third option is the combination of both, using a central authentication server for the single authentication and for the sign-on OpenID or SAML. The next chapter shows an overview of the proposed architecture and before going more into details by discussing the general concept.

[edit] Proposed Architecture

Before going more into technical details the following figure shows the proposal for the Single Sign-on concept. The following parts provide some more detailed information, and give further reasons for it.

Image:SSO_Architecture.jpg

[edit] General Concept

The best choice for one of the three different options depends hardly on the goals, the requirements and the amount of effort, which should be invested in implementing the solution. The following will give a short introduction in what they are capable to achieve.

[edit] Centralised Authentication Server

The architecture of the system would change in a way, that instead of providing an authentication method on every single server, the authentication would be handled with the help of an additional component, the authentication server. This component can work as proxy (CAS) or gateway (JOSSO) and use sessions and cookies to communicate to the application whether a user is authenticated or not. This is done on the application side by using libraries, which are offered for every implementation and mostly supports several programming languages. The database with the credentials can be set up apart from the concrete server using any standard technologies (LDAP, MySQL etc.). The benefits and drawbacks of this kind of architecture are:

Benefits:

  • Open Source components available
  • No big changes to the current components
  • Easy to adapt
  • Scalable

Drawbacks:

  • Using it without special modifications, user still would have to create account


This approach focuses more on the user-perspective and hides the authentication process for each application from the user. From the user-perspective there is only one single UI for the login on every application needed and the set of supported applications appears as a coherent system environment.

[edit] Decentralised Authentication

The decentralised approach focuses more on the application perspective and the goal is to decentralise the management of the user-credentials and abstract this from the single application. The two basic mechanisms for this are OpenID and SAML. Details about this will be given after the general technical overview. Focusing on the authentication both approaches work in a similar way, assuming a web-browser as the client. When a user wants to access a protected application, the user will be redirected to the identity provider. There the user has to be authenticated. Afterwards, the user will be redirected again to the relying party, which provides the application. In the last step the relying party validates the authentication with the identity provider. Finally, the user is logged in. Benefits:

  • Open standards
  • Easy to adapt
  • scalable
  • One identity provider handles user-credentials – user can select, which account to use

Drawbacks:

  • Application-centric approach – user would have to go through some sign-in process on every application

[edit] Combination of the decentralised and centralised approach

The two concepts, which were presented before solve two different problems within the single-sign on idea. The first, centralised approach, focuses on the ability of sharing the sign-on process for a set of different applications, while the decentralised approach focuses more on the abstraction of the sign-on process for the single applications. Each approach has its drawback regarding the requirements. The combination of both approaches would help to eliminate those drawbacks by the cost of more work for the implementation of the concept. The idea is to use a central authentication server, which handles the authentication for a set of applications, and further, OpenId or SAML as an identity provider, so that the user does not have to bother with creating a new account with additional username and password.

Benefits:

  • Combines the benefits of the first two approaches

Drawbacks:

  • More complex implementation

[edit] Proposal

The overall goal of the SSO concept is to improve the usability on all the different components, which are provided by maemo.org. The first user-centric concept would improve the usability a lot, even though the user would have to create still a new account to sign on. On top of this it would be good to combine this concept with the ability of using a public identity provider to give the user the choice and without bothering with new credentials. To summarise, two steps have to be done:

  1. Implementation of a centralised authentication server
  2. Enhance 1. by implementing the integration of a public identity provider


[edit] Available and commonly used tools

Goal of this chapter is to provide an overview of available tools regarding the already existing architecture and the result of the analysis of the general concept. After summarising the required features, which should be provided by the centralised authentication server, some implementations for will be shown and compared.

[edit] Centralised Authentication Server

REQUIREMENTS The implementation of the server has to follow some requirements, which are given by the current setup of the different applications, provided under maemo.org domain. A list of them is provided in the following list:

  • Support of the different programming languages, which are needed by the used components (PHP, PERL, Java)
  • Support of OpenID/SAML
  • Easy to adapt to service applications

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 all of the required 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.

[edit] Proposal

The proposal is in this case to use CAS as the authentication system. In the following it will be compared to the other two solutions.

Client The service is quite flexible in the client support and the adaptation within the clients seems to be really straight forward. Further, from the client-side of view, there exist already a plugin for the mediawiki. Compared with the two other implementations, CAS supports clearly more client implementations and all these in an easy way. The support of very different applications is part of the strategy of CAS (“CASify applications”). JOSSO as well as OpenSSO concentrate clearly on Java client support, even though it is possible to work around these limitations. The CAS approach seems to be more reliable and it is regarding the wide client support definitely more scalable. New applications can be integrated quite easily, and the already existing architecture does not have to be changed extensively. Only the sign-on part of the applications has to be changed with the help of the mentioned libraries. The server runs as a completely separated component. The user database on application side still can be used to authorise actions for the user. Only the profiles have to be mapped to the new user data.

Service All the services support almost the same range of features. Important is the integration of external user data management by a database or LDAP. CAS supports this, as well as the others. Another critical feature is the support of open authentication protocols like OpenID and SAML. Both, CAS and JOSSO, are extensible regarding to this. OpenSSO focuses more on SAML, but there exist also a (btw. quite old) extension for the OpenID support. An advantage of JOSSO and OpenSSO is the support of authorisation methods within the authentication server. But here is the question if that is really the intention of an authentication service in general. The architecture allows authorisation methods on every single component, which still could be used, when the only the authentication is done by an additional server.


[edit] Decentralized Authentication

On top of the central authentication service, some decentralize user identity management system could be integrated. Two of the most important systems are already briefly mentioned, namely OpenID and SAML. Some more technical details will be introduced in the following.

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.

SAML will be updated soon


[edit] Proposal

IDEA: OpenID (maemo.org as OpenID Provider?!?) - will be updated soon


[edit] References

will be updated soon


More https://bugs.maemo.org/show_bug.cgi?id=3340

[edit] Implementation information

Retrieved from "http://bugs.maemo.org/Task:Single_sign-on"