Authorization

MEF-Auth is a framework for authorization, for controlling what actions a user is allowed to perform. It uses an Subject-Role-Target approach:

• Subject -- is a user or group of users
• Role -- is a role that users (or groups of users) have, such as "Editor". A role is simply a string and has no other meaning to authorization.
• Target -- is something that is being authorized, such as as admin dashboard page.

MEF-Auth is rule-based. You add a set of rules to define the authorization that you need in your app. Each rule is of the form: subject has role on target. For example,

Managers have VIEWER role in reports

This rule says that the user-group "Managers" has VIEWER role in the reports portion of your app. It would prevent users who are not managers from seeing reports. To use this rule in your code, add this

ensureIsAuthorizedFor("VIEWER", "reports");

This method call will check that the currently logged in user has the "VIEWER" role for the target called "reports", and throw an exception if not. It will check rules for the user and for any groups the user is a member of.

Subjects begin with no authorization, and only gain authorization when there are rules that apply to them.

In order to be flexible, Auth does not refer to any of your models or database tables. It uses subjects as a form of indirection. Create a subject for each user in your system. You User table typically has a reference to its subject

 Long subjectId;

Targets are also a form of indirection. Create a target to represent a scope for which you want to control access. For example a medical system might have doctors and patients, where a patient HAS-MANY doctors. To ensure that a patient's data can only be viewed by his doctors, create a target on each patient object and then add a rule for each of his doctors:

 {doctor} has EDITOR role on {target of patient}

And use this in your code to do the authorization

ensureIsAuthorizedFor("EDITOR", patient.targetId);

Targets are flexible. They can reprsent a single object, as described above, or a larger scope. For example, you could give certain developers rights to view performance logs with a rule. First, create a group PerfDevelopers and add the relevant developers to this group. The create a target called "perf-logs", and add a rule

 PerfDevelopers have VIEWER role on perf-logs

Targets are, in fact, optional. If missing (i.e. null) then the rule states that the subject has a role, and this role is universal, not scoped to any target.

 SysAdmins have SUPERUSER role

To use this in your code, use the hasRole method

 ensureHasRole("SUPERUSER");

Lastly, subjects themselves can be targets. For example, managers can be given editing rights on their employee's vacation requests with a rule for each of his employees

{subject for manager X} has "EDITOR" role for {employee subject}

Alternatively, you could create a user-group of each manager's employees and then have a single rule

{subject for manager X} has "EDITOR" role for {manager's user-group subject}

Data Model

The auth system has the following models

AuthSubject
  id
  type //'u' for user, 'g' for group, and 't' for target
  name
   
AuthSubjectGroup
  groupId; //subject id of the group
  subjId; //a member of the group
       
AuthRole
  id
 name
      
AuthSRTRule
  subjId
  roleId
  targetId