Currently the only Overlord project that does any fine grained authorization is APIMan.  All other projects basically either allow you to do everything or nothing.

(Note: actually DTGov does support some roles that are used when creating human tasks from dtgov workflows, but this is all handled by jBPM)

In this article I will describe the current approach to authorization in APIMan and then discuss how it might apply to our other projects (in particular RTGov).

API Management Authorization Summary

First you must understand the basic entities found in the APIMan project.  At a very simple, high level we have the following entities:

1. Organization
2. Service
3. Application

Much like github, an Organization is basically a container within which Services and Applications are created.  The system supports multiple Organizations, each with N number of apps and services.

We decided that all authorization will be driven by membership in roles qualified by organization name.  So the level of granularity of authorization permissions is limited to the Organization level.  What this means in practice is that users must be made members of roles within an Organization.  The role membership grants the user a set of Permissions (e.g. ORG_VIEW, ORG_UPDATE, APP_CREATE, etc...), with each permission qualified by the role's Organization qualifier.

Whenever a user attempts to perform an action, an appropriate authorization check is performed first.  For example, if the user attempts to create an Application within the "FooOrg" organization, the system does something like this:

if (!currentSecurityContext.hasQualifiedPermission("APP_CREATE", "FooOrg")) {
  throw new NotAuthorizedException();
}

And so the user can only perform the operation if she has a role within the FooOrg organization and that role grants the APP_VIEW permission.  For instance, the user might have the "Application Developer" role and that role might be configured to grant the APP_VIEW permission.

API Management Implementation

So how is this authorization approach implemented in APIMan?  Well currently APIMan has a pluggable persistence layer for dealing with the Organizations and Applications and Services and whatnot.  A separate interface exists to handle the IDM related entities such as Users, Roles, Memberships, and Permissions.  The idea is that we should be able to plug in new back-ends for the IDM related functionality.  This is important because there will likely be use cases where deployers of apiman will want to use an LDAP directory or some other source of identity.

The current implementation stores the IDM related entities in the same JPA persistence unit as the non-IDM related entities.  But the interfaces are separated specifically so we could get role/permission information from some other source.

(Note: it's worth pointing out that I think the most problematic issue facing an authorization implementation is how to filter entity listings or entity search results.  For use-cases where a listing of entities must be filtered by the user's permissions, it is most likely extremely important to have a way to push authorization criteria into the query language (e.g. SQL) so that queries can be efficient and properly paged)