Single Sign-On

Last modified by Vincent Massol on 2024/02/26 17:55

 XWiki
 Feature
 Dropped
 

Description

This page will hold all information about my Google Summer of Code Single Sign-On project. My next step will be to integrate an OpenID library so that XWiki supports OpenID authentication out of the box. Then I'll add the provider functionality so that each user gets an OpenID URL which he can use everywhere on the net.

OpenID Integration

Login

Logging in with OpenID requires the user to input an OpenID URL. Therefore the default login screen needs to be modified. Below is a mock-up for a possible design. The OpenID box should be rendered only if OpenID support is enabled. 

login-form.gif

Registration

Also the registration form has to be altered so that a user can use his OpenID to create an account. Again the OpenID part is displayed only if OpenID support is enabled.

OpenID has a mechanism called attribute exchange (respectively simple registration extension) which allows the user to perform a registration without entering all his data on every site. The OpenID provider sends user data such as name or email address back to the site which in turn can prefill the registration form then. So the registration process for an OpenID user would look as follow:

  1. Enter the OpenID in the registration form
  2. Click on "Register with OpenID"
  3. The user is redirected to his OP where he has to authorize the process
  4. The user is redirected back to the site where a prefilled registration form is shown so that he can verify that all values are right
  5. The user finishes the registration with one further click.

registration-form.gif

Proposed Architecture

I'll begin with the integration of full OpenID support. That means that XWiki can act as both, as RP and as OP. To achieve this I'll use the OpenID4Javalibrary.

OpenID Authentication

The first thing I will implement is OpenID authentication support (XWiki as RP). Therefore I need to modify the login and the registration screen (proposals are shown above).

Furthermore I need to store the needed OpenID URL. This could be done by adding a property to the XWikiUsers class but this is probably not the best way to achieve it since it tightly couples the OpenID stuff to the user class. So I'll create a new XClass (XWiki.OpenIDUrl) which is then attached to the user class (thanks Sergiu for the hint).

Then I'll create a new authenticator class which gets the OpenID URL from the login form and forwards the user to his OP.

Finally I need to create a special page (or better endpoint or handler) which processes the response of the OP and either logs in the user or displays an error message.

OpenID OP

To make XWiki act as an OP a servlet that receives all OpenID requests is created. If the user isn't logged in yet, it will be redirected to the login page and the request is stored until he is authenticated. Then the request is evaluated and the user is asked whether he likes to authorize the request (i.e. log in on the requesting site) or cancel it. Finally the user is redirected back to the requesting site.

Every user will get an unique OpenID that he can use on other sites. It is in the form of XWIKI-URL/openid/USERNAME, e.g. http://www.xwiki.org/openid/MarkusLanthaler. But to login on another OpenID 2.0 site it is enough to enter http://www.xwiki.org/openid/, the rest is handled automatically behind the scenes.

OP support can be turned on or off in xwiki.cfg by setting xwiki.authentication.openid.server.enabled to 1 or 0.

Open Questions

  • How should it be possible for a user to bind an OpenID URL to his already existing account?
  • How should the issued OpenID URLs look like? http://www.xwiki.org/xwiki/bin/view/XWiki/UserName seems to be to long for me. Something like http://www.xwiki.org/user/UserName would be much better in my opinion. What do you think? Would that be possible with the existing architecture?
  • What about user recycling, i.e. if a user (Alice) deletes his account and another one (Bob) creates an account with the same user name afterwards what should happen? Bob would be able to log-in to all sites on which Alice used her XWiki account. Yahoo for example solves this by appending a fragment like #fk32j to each OpenID. So the OpenID URL http://www.xwiki.org/user/UserName would become http://www.xwiki.org/user/UserName#fragment -> NOT NEEDED

Glossary

Since I often need to use the same terms during my project and I think that not everyone know those terms and abbrevations I created a little glossary

  • RP (Relying party): A website that supports OpenID authentication
  • OP (OpenID provider): The site that manages the OpenID account to which an user is redirected if he logs in on a site supporting OpenID

Specifications

Frameworks

OpenSSO

  • Full SAML 2.0 support
  • Very active and large community
  • Common Development and Distribution License (CDDL)
  • Supports OpenID 1.1 via a extension (plugin)

esoe

  • Apache 2.0 license
  • Built using OASIS SAML 2.0 specification
  • Supports SAML 2.0 (GET and POST profile, artifact profile support is planned)
  • Supports Shibboleth and OpenID (federated authentication)
  • Uses OpenID4Java for OpenID support
  • Authentication support for LDAP, Active Directory, ... (extendable)
  • Support for multi-factor authentication

Libraries

OpenID4Java and OpenIDCards package

  • OpenID 2.0 support (provider and consumer)
  • Higgins STS
  • Infocard OpenID Provider
  • Apache 2.0 (OpenID4Java, Infocard OP)
  • Eclipse Public License 1.0 (Higgins STS)

NetMesh InfoGrid

  • OpenID support (provider and consumer)
  • Light-Weight Identity (LID) support (provider and consumer)
  • Yadis support
  • Licensed under a Sleepycat-like open source/commercial license

 


Tags: gsoc
    

Get Connected