Page History

1.0 Abstract

This is a proposal to make it possible to externalize user management so that Roller can pull user profile and role information from a separate user management system.

2.0 Background

Here's an explanation of Roller's current user/role management, the perceived problems and proposed solutions.

2.1 Roller manages it's own users and roles

So that it can stand-alone without an external user repository, Roller stores users and role information in it's own database tables.

...

Those tables are represented in Roller by the User and UserRole objects, simple POJO objects stored by Roller's ORM based UserManager.

2.1.1 The problem

For sites that have an external user repository or user permissions system, this is a problem. Some would like user information like email address, locale, timezone, fullname and etc. pulled from an external system. Some would like user's roles to be pulled from an external system. Some would like both.

2.1.2 The solution

Reduce the User class down to just two fields, id and username. Everything else goes into a new UserProfile class. UserProfiles can be stored externally so Roller should obtain them through a new User Respotory API

...

username
password
screenName
emailAddress
locale
timezone
biography
etc.

2.2 Roller authentication is

...

managed via Acegi

Roller uses a framework called Acegi to handle authentication and authorization. Instead of relying on the authentication and authorization features built into the container on which Roller runs, Roller relies on Acegi.

...

Acegi is implemented as a Servlet Filter, which intercepts each request and decides if the user is authenticated, needs to login first, etc. Acegi takes care of routing the user to the login page and back to the original page that the user requested. Acegi wraps the ServletRequest so that it can return the
right value when request.getUserPrincipal() is called by the application.

2.2.1 The problem

Using Acegi makes Roller installation painless in standalone situations, but some Acegi skills are required to reconfigure Roller to authenticate against an LDAP system. And the only SSO system that Acegi supports out of the box is Yale CAS. And some folks would like to disable Acegi to take advantage of the auth & auth services that are built into containers now, e.g. SSO support that's built into Websphere, Glassfish, etc.

2.2.2 The Solution

Make it possible to turn off Acegi by modifying web.xml and to extend the Roller application class RollerContext to init without Acegi. Moving forward, we should not introduce further dependencies on Acegi in Roller.

2.3 Acegi manages URI authorization

These rules in Acegi's configuration (security.xml) file govern URI based
authorization used in Roller.

...

The Problem? There's no problem here. When operating without Acegi, Roller will
have to be configured with a web.xml file that specifies those contraints.

2.4 Roller manages all other authorization involving user roles

Roller also does it's own authorization checks on user Roles.

...

• View set the Admin options in the tabbed menu
• Modify another user's profile
• Edit any weblog
• Set pinned field of a weblog entry
• Use RAP web services

2.4.1 The Problem

Because Roller uses the ORM system to load a User's Roles, the roles must come from the database. And because Roles are part of the User, some sort of join must happen to load each User object with Roles.

2.4.2 The Solution

Instead of relying on ORM supported role methods in the user object, Roller front-end code should call the user manager:

...

Roller will include a User Repository API that stores data in the Roller database. Other implementations can be plugged in via DI.

3.0 Requirements

Make it possible for Roller to optionally:

...

You can stop reading here... the rest is TBD

4.0 Issues

Issues to be considered

5.0 Design

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

6.0 Comments

Other can leave commments here.