Show last authors
1 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.
3 = OpenID Integration =
5 == Login ==
7 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.
9 (% class="imgcenter" %)
10 (((
11 [[image:login-form.gif]]
12 )))
14 == Registration ==
16 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.
18 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:
20 1. Enter the OpenID in the registration form
21 1. Click on "Register with OpenID"
22 1. The user is redirected to his OP where he has to authorize the process
23 1. 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
24 1. The user finishes the registration with one further click.
26 (% class="imgcenter" %)
27 (((
28 [[image:registration-form.gif]]
29 )))
31 == Proposed Architecture ==
33 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 [[OpenID4Java>>]]library.
35 == OpenID Authentication ==
37 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).
39 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).
41 Then I'll create a new authenticator class which gets the OpenID URL from the login form and forwards the user to his OP.
43 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.
45 == OpenID OP ==
47 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.
49 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. But to login on another OpenID 2.0 site it is enough to enter, the rest is handled automatically behind the scenes.
51 OP support can be turned on or off in //xwiki.cfg// by setting //xwiki.authentication.openid.server.enabled// to //1// or //0//.
53 == Open Questions ==
55 * How should it be possible for a user to bind an OpenID URL to his already existing account?
56 * How should the issued OpenID URLs look like? {{{}}}//UserName// seems to be to long for me. Something like {{{}}}//UserName// would be much better in my opinion. What do you think? Would that be possible with the existing architecture?
57 * 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 {{{}}}//UserName// would become {{{}}}//UserName**#fragment**// -> **NOT NEEDED**
59 = Glossary =
61 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
63 * **RP (Relying party):** A website that supports OpenID authentication
64 * **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
66 = Specifications =
68 * [[OpenID Authentication 2.0>>]]
69 * [[OpenID Attribute Exchange 1.0>>]]
70 * [[OpenID Authentication 1.1>>]]
71 * [[OpenID Simple Registration Extension 1.0>>]]
73 = Frameworks =
75 == [[OpenSSO>>]] ==
77 * Full SAML 2.0 support
78 * Very active and large community
79 * Common Development and Distribution License (CDDL)
80 * Supports OpenID 1.1 via a extension (plugin)
82 == [[esoe>>]] ==
84 * Apache 2.0 license
85 * Built using OASIS SAML 2.0 specification
86 * Supports SAML 2.0 (GET and POST profile, artifact profile support is planned)
87 * Supports Shibboleth and OpenID (federated authentication)
88 * Uses OpenID4Java for OpenID support
89 * Authentication support for LDAP, Active Directory, ... (extendable)
90 * Support for multi-factor authentication
92 = Libraries =
94 == [[OpenID4Java>>]] and [[OpenIDCards>>]] package ==
96 * OpenID 2.0 support (provider and consumer)
97 * Higgins STS
98 * Infocard OpenID Provider
99 * Apache 2.0 (OpenID4Java, Infocard OP)
100 * Eclipse Public License 1.0 (Higgins STS)
102 == [[NetMesh InfoGrid>>]] ==
104 * OpenID support (provider and consumer)
105 * Light-Weight Identity (LID) support (provider and consumer)
106 * Yadis support
107 * Licensed under a Sleepycat-like open source/commercial license

Get Connected