How to Specify And Use Role Permissions

Draft 0.1
Dec 15, 2000
Ted Lee (tlee@startups.com)

1. Applicability

Read this document when all of the following are true:

You want to make sure a Startups.com user has logged in before accessing a page in the site.
You want to make sure a Startups.com user has permission to access a page in the site.
You have read and understood "How to Use Basic Unified Login".
You want to give users different permissions to access different pages, but you don't want to define separate roles for this purpose.

If this document doesn't meet your needs, you may want to look at:

How To Use Basic Unified Login

Background

The basic unified login model implements permission-based security, where users may be required to contain a particular role before being allowed access to a particular page. However, there are some situations where this level of security may not be granular enough. For instance, perhaps it would be desirable to allow users with an admin role to have different levels of admin permissions. Under the basic unified login model, you would have to create a separate admin role for each permission, which would be cumbersome.

This document describes ways to customize the login process so that nearly any level of detail about a user or role may be used to determine access to a page.

2. Steps for Defining And Using Role Permissions

Basically, you want to override the isAccessibleTo() method defined in Model so that it checks whatever you need checked for access to the page. This could be anything, but to be concrete we'll describe in this cookbook an example of adding some permissions to a role as a bunch of boolean flags. You may choose to implement permissions in a different way, but the basic steps will be similar.

2.1 Define Permissions For The Role

Let's assume we have a role called ResourceLocatorAdminRole. We want to add some permissions to the role, so that certain resource locator administrators have more privileges than others. For the purposes of this example let's say that it is sufficient to add permissions as simple boolean bits (this could be done in much more sophisticated ways):

public class ResourceLocatorAdminRole extends UserRole {
    private boolean isAllowedToDeletePostings;
    private boolean isAllowedToCredit;
    private boolean isAllowedToModifyPermissions;
    ...

    public boolean isAllowedToDeletePostings() {
        return this.isAllowedToDeletePostings;
    }

    public void setAllowedToDeletePostings(boolean isAllowed) {
        this.isAllowedToDeletePostings = isAllowed;
    }

// etc.
...
}

2.2 Override `isAccessibleTo()` in `Model` subclasses

Model contains a method which implements the basic unified login access permissions:

public boolean isAccessibleTo(StartupsUser user)

The implementation of this method looks something like this:

public boolean isAccessibleTo(StartupsUser user)
    if (getRequiredRole() == null) {
        return true;
    }
    if (user == null) {
        return false;
    }
    return user.containsRole(getRequiredRole());
}

We want to override this method for Models representing pages that need to check the permissions we just defined in step 2.1. For example:

public class AdminModifyPermissionsModel extends Model {
    public boolean isAccessibleTo(StartupsUser user) {
        if (super.isAccessibleTo(user)) {
            ResourceLocatorAdminRole theRole = (ResourceLocatorAdminRole)
                    user.getRole(ResourceLocatorAdminRole.class);
            return theRole.isAllowedToModifyPermissions();
        }
        return false;
    }
    public Class getRequiredRole() {
        return ResourceLocatorAdminRole.class;
    }
    public String getPermissionDeniedURL() {
        return "/resourcelocator/NotAllowedToModifyPermissions.jsp";
    }
}

The exact implementation of isAccessibleTo() depends on how the permissions are defined.

3. Design Discussion

There are many ways to design an access control system. Rather than overdesign up front, we've chosen to implement a solution that should work 80% of the time (using roles as access permission flags) while allowing for the possibility of making things more complex (via overriding isAccessibleTo()). In the example we've purposely chosen to show a simple example, but it could easily be extended for a more hierarchical system. But the point is that right now we don't have time to anticipate our needs exactly so we go with the simple thing that can be extended.

Known Problems

This has never been tested!!!!
Only addresses access, doesn't address how to make the same web page render differently based on the permissions. For instance, we might want to send the user to the same page regardless of permissions that they have, but only show certain items on the page if they have the right permissions.
No way exists right now to create a custom model for the permission denied jsp. That means the permission denied jsp must be static if it's not using the default.

4 Version History

0.1 First Version