Versions Compared

Key

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

Name

Externalize User Permissions

StatusProposal under development

Withdrawn from consideration

Target Release

Roller Weblogger 4.1

Original Authors

Dave Johnson

...

This is a proposal to make it possible to externalize user permissions so that Roller can pull user-weblog permissions from a separate user permissions system.

1.0 Abstract

For ease of installation and management, Roller is able to manage it's own users permissions without relying on any external system other than its RDBMS. We definitely don't want to lose that easiness, but we do want to make it possible to plug Roller into existing sites and applications that have their own permissions management systems.

This proposal outlines a plan to make it easy to hook Roller up to an external user permissions system. The general approach is to define a User Permissions 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 permissions systems.

3.0 Requirements

  • Enable Roller to optionally read/write user-weblog permission information in an external system instead of it's relational database.
  • Define a User Permissions API and make it possible to plugin User Permissions API implementations without having to extend a UserManager implementation.

4.0 Issues

Issues raised and addressed during review process. TBD

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

5.1 Roller manages user-weblog permissions

In addition to roles, which are global across a Roller site, Roller also manages each
user's permissions to access weblogs. There is a many-to-many relationship
between users and weblogs and it's stored in a database table: – User permissions within a website

Code Block

-- User permissions within a website
-- permission_mask: bitmask 000 limited, 001 author, 011

...

 admin
-- pending: pending user acceptance of invitation to join website

...


create table roller_user_permissions (

...


   id              varchar(48) not null primary key,

...


   website_id      varchar(48) not null,

...


   user_id         varchar(48) not null,

...


   permission_mask integer not null,

...

 
   pending         $db.BOOLEAN_SQL_TYPE_TRUE not null

...


);

There are three permission levels:

  • limited: can edit draft weblog entries only, can submit for review
  • author: can edit draft and publish weblog entries
  • admin: can author and can manage users, weblog settings, theme and etc.

Each User object provides access to the User's weblog permissions. When a user
logs isin, we use this to display the user's list of weblogs.

User

Code Block

public List getPermissions()

...


public void setPermissions(List perms)

Each Weblog object provides access to the Weblog's permissions. When a weblog
admin uses the manage members page, we use this information to display the
list of weblog members and the permissions levels of each.

Weblog

Code Block

public List getPermissions()

...

 
public void setPermissions(List perms)

...

 
public void removePermission(WeblogPermission perms)

...


public int getUserCount()

...


public int getAdminUserCount()

WeblogEntry

Code Block

public boolean hasWritePermissions(User user)

5.1.1 Problem

Permissions cannot be managed by external system because the User to Permissions
to Weblog relationship is managed by the ORM, the information must be stored in
Roller database tables and cannot be externalized and managed by another system.

5.1.2 Solution: User Permissions API

First, we remove the dependence on ORM for permissions. Insead calling ORM supported methods on the Weblog and User classes, the Roller
front-end will call the Roller UserManager to access permissions information. We'll add these new methods to accommodate that:

New methods in UserManager

Code Block

public Set<WeblogPermission> getWeblogPermissions(Weblog weblog)

...


public Set<WeblogPermission> getUserPermissions(User user)

...


public void grantPermissions(String username, WeblogPermission perm

...

)

...


public void

...

 removePermission(String username, WeblogPermission perm)

...


public int getUserCount(Weblog weblog)

...


public int getAdminCount(Weblog weblog)

Second, to allow us to plugin alternate user permissions systems Roller's default UserManager implementation will then call a User Permissions API
interface to store and retrieve permissions:permissions. This could be done in a generic way by allowing user permissions to be granted on any object of any class.

For example, this API allows you to grant permissions on specific objects and uses a mask for permissions as we do now in Roller.

User Permissions API

UserPermissions interface methods

Code Block

...


public void grantPermission(
   String username, String objClass, String objectId, int mask)

public void removePermissions(
   String username, String objClass, String objectId, int mask) 
   
public Set<Permission> getUserPermissions()
public Set<Permission> getUserPermissions(String objClass)
public Set<Permission> getUserPermissions(String objClass, String objectId)
public Set<Permission> getObjectPermissions(String objClass, String objectId)

Permissions bean

Code Block

int    mask
String objectClass
String obectId    

...

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

5.2 Specific changes to Managers, POJOS, Actions and JSPs

TBD

6.0 Comments

Please comment on the dev mailing list.