Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Name

Externalize User Management

StatusProposal under development

Withdrawn from consideration

Target Release

Roller Weblogger 4.1

Original Authors

Dave Johnson

...

This proposal outlines a plan to make it easy to hook Roller up to an external user management system for user information, user profiles and user roles. The general approach is to define a UserRepostory API, provide a default implementation for Roller, and change UserManager to use that API. Developer could then provide alternative implementations of that API to plug in their own user management systems. Also, to allow more authentication options, we should make it possible to configure Roller to use CMA instead of Acegi.

2.0 Requirements

Proposal satisfies these requirements.

  • Enable Roller to optionally read/write user profile information in an external system
  • Enable Roller to optionally read/write user role information in an external system
  • Increase the number of authentication/authorization options available in Roller by making it possible to configure Container Managed Authentication (CMA) and not only Acegi.
  • Define a User Management API and make it possible to plugin User Management API implementations without having to extend a UserManager implementation.

3.0 Issues

Issues raised and addressed during review process. TBD.

4.0 Background and Design

To understand this proposal you need to understand how Roller's existing user management system works. So here's an explanation of Roller's current system, the perceived problems and proposed solutions.

...

4.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. These tables, known as rolleruser and userrole are shown below (using MySQL DDL syntax).

...

Those tables are represented in Roller by the User and UserRole objects, which are POJOs stored by Roller's UserManager via Object Relational Mapping (ORM) technology (i.e. Apache OpenJPA).

...

4.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.

...

We need to decide which approach to take, or come up with new ones. Now, let's move from user profiles to user authentication.

...

4.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.

...

4.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. Unfortunately, the only SSO system that Acegi supports out of the box is Yale CAS. Plus, some folks would like to disable Acegi to take advantage of the powerful auth & auth services that are built into containers now, e.g. SSO support that's built into Glassfish, Websphere, JBoss, etc.

...

4.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.

...

  • There's more (still investigating...)

...

4.4 Roller manages all other authorization involving user roles

Roller also does it's own authorization checks on user Roles. For each new user session, Roller creates a RollerSession object. RollerSession calls request.getUserPrincipal().getName() to get the user name, fetches corresponing User object from UserManager and holds on to that User object.

...

  • 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

...

4.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.

...

4.4.2 The Solution

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

...

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

  • Enable Roller to optionally read/write user profile information in an external system
  • Enable Roller to optionally read/write user role information in an external system
  • Increase the number of authentication/authorization options available in Roller by making it possible to configure Container Managed Authentication (CMA) and not only Acegi.

...

4.5 Specific changes to Managers, POJOS, Actions and JSPs

TBD

6.0 Comments

Please comment on the dev mailing list

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.