Page History

...

Abstract

This project aims to add OpenID support to Roller both for user accounts and for those leaving blog comments. Make it so that new and existing users can choose to tie their user account to an OpenID identity and use that for all subsequent logins. And, make it so that bloggers can require that folks login via OpenID before leaving a comment. These features could be implemented by modifying Roller's existing Spring Acegi configuration and/or by documenting how to use a Container Manager Authentication (CMA) configuration, e.g. OpenSSO paired with a Servlet Container. Either way, it is likely that you'll have to write some custom Java code to make this work.

It's quite evident that the number of online user accounts increases rapidly. It's almost impossible to remember logins and passwords on each website, and that's why systems that use authentication servers have valuable priority. As far as the Roller blog server is an application which provides access to different blog sites, and all of them require authorization, it can be very useful to reduce the amount of logins at different services to minimum. It can be done by implementing the OpenID identification to the server.

Benefits for the community

The main aim of the project is to increase the efficiency of the authentication and authorization processes at the Roller blog server by managing logon to several services and users' identity in one place via an authentication server with OpenID technology. Using this technology, we'll achieve cross-application and cross-domain single sign-on (SSO). As a result, the users will be more satisfied as they won't have to remember logins and passwords from every website, and just use single OpenID identifier. And the number of people using Roller blog will increase.

With the fulfillment of the objectives previously exposed, the community will see beneficiary in the following aspects:

1. Support single logon for user accounts and for users who leave blog comments;
2. Existing users will be able to tie their accounts to the OpenID identity for further use;
3. New users will have to provide only OpenID identity for further identification;
4. If the user is not logged-in and wants to leave a comment, the system will redirect him to the login page;
5. Integration of the new authorization system to the existing one, which is built on Spring Acegi framework;
6. Support for multiple profiles (for example, provide different names and info at different services).

Requirements

• Add OpenID support to Roller for user logins

Other requirements to be determined during project execution.

Issues

Issues to be considered.

To be determined during project execution.

Design

List and describe new manager methods, Struts actions, JSP pages, macros, etc.

To be determined during project execution.

...

OpenID is a technology that allows users to use one username/password pair to login to large number of web sites, but to never have to reveal their password to any of those sites. Instead of establishing a username/password pair on each site, a user instead registers with an OpenID provider site (e.g. claimid.com) and receives in return a unique OpenID identifier URL. When logging into a site that supports OpenID logins, known as an OpenID consumer site, the user specifies this URL to the consumer site, is directed to the provider site to login and then back to the consumer site in a logged in state.

This proposal is for adding OpenID support to Roller so that Roller can act as an OpenID consumer.

Requirements

Here are the basic requirements to be satisfied by this proposal:

• Allow new users to register and login via OpenID
• Allow existing users to login via OpenID
• Allow site operators to choose one of three modes of operation:
  • Disabled: no OpenID support and no evidence of OpenID in the Roller web UI
  • Hybrid: allow users to login via either username/password or OpenID identifier
  • Only: require users to login only via OpenID identifier

Issues

Here are the major issues we discussed during the development of this proposal:

• Allow users to specify more than one OpenID? Decision: no, one is sufficient
• Allow commenting users to login via OpenID? Decision: good idea, but we'll do this later
• Add OpenID specific methods to Roller's User Manager? Decision: no, use generic user attributes to store each user's OpenID identifier instead.

Design

Here is an overview of the design of the OpenID consumer support in Roller:

Use Spring Security's OpenID support

We will use Spring Security v2.0.3 (the latest release) and its OpenID support feature.

New database table and POJO

We will add a new database table 'roller_userattribute' and a new POJO UserAttribute to store each user's OpenID identifier URL. Later, this table can be used to associated other data with each user.

New UserManager methods

Add methods for setting and getting user attributes.

New startup properties

Add a new startup property called 'authentication.openid' with three possible values: disabled, hybrid and only. See the requirements for the meanings of these strings.

Changes to registration form

Add an OpenID identifier field that will be shown in hybrid and only modes. Here's what the form will look like in hybrid mode:

Image Added

Changes to login form

Add an OpenID identifier field that will be shown in hybrid and only modes. Here's what the form will look like in hybrid mode:

Image Added

Changes to user profile form

Add an OpenID identifier field that will be shown in hybrid and only modes.

...

Project Plan

1. Examine the application structure and the features of the existing authorization system, built using the Spring Acegi framework. Understand, what types of security filters are used and how they can be replaced. Outline, what features to change and what to edit in the existing system.Examine what technologies and frameworks to use in this project (JSF, Struts). Java Server Faces technology will be used for writing the code for client/server collaboration in the web application.
2. Plan the main functionality of the project and install required libraries to the system.
3. Choose the OpenID server. It is possible to use the external OpenID server (the most popular is AOL), or install our own identity server, which will allow us to act as an OpenID Provider. There are several options there. At first, we could run one just for the application's needs (for testing and debugging, probably), also - for a community of users or for the general public. It is not required to register or obtain permission from anyone; just need to run an OpenID identity server on the site. This requires the ability to install and run some software on the web server. There are a lot of existing OpenID identity server implementations, some of them are written in Java (NetMesh InfoGrid LID Java and Atlassian's Crowd).
4. Release the main functionality - add necessary classes and scripts, scripts, database tables and Spring Security filters.
5. Change the visual interface of the application (add authentication prompt to ask users for their OpenID identifier rather than their username and password).
6. Release the option of storing users' preferences indicating whether they want to approve the authentication with the website 'temporarily', 'always' or 'not at all'.
7. Explore ways to establish a shared-secret with the OpenID provider (it is the alternate way of security protection - in Spring Acegi technology it is provided by Filters), through association from the application and write scripts that allow the system to redirect user's identifiers to the OpenID Provider and receive response.
8. Test the system and write necessary documentation.

...

• 26th of May
  • Initial planning of the project and research
  • Deliverable: Document of detailed description of the project.

• August, 11th July, 7th (midterm)
  • To this point the code of the application will be given.
  • Deliverable: Coding necessary to implement the OpenID authentication + documentation.

• August, 11th 18th (endtermdeadline)
  • In this point, corrections would be done that make lack to the previous code.
  • Deliverable: Documentation on the project.

...