Ideal Security Model

Permissions Model

Actors

When dealing with permission for a complex system such as OpenRegistry, there are many actors involved. They are described below:

• Everyone - everyone really means anyone that tries to access the system regardless of who they are and whether we know about them. In general, "everyone" would be given some form of read access to basic directory information, and that's it.
• Authenticated - authenticated users are people we've vetted at some point, and who have a login to the system. They may gain more advanced read access to things like directory information.
• Self - Self is you. Generally, its things you can do to yourself. I.e. you can probably edit your own home address.
• User/System - A particular person or system may have access to certain privileges (i.e. McCorrmick may be able to edit anyone's name).
• Role/Attribute - People or Systems with particular roles or attributes (i.e. any Software Developer, or anyone with blue eyes) may be able to do something or have extra permission.

Domain

Domain means the items that we are trying to secure. This includes:

• Generic objects, such as person, person.roles, person.roles.addresses, etc.
• Specific instances, such as person[personId=45678], person.roles[roleId=434], person[personId=45678].roles[roleId=434].addresses[addressId=1]
• Attributes, such as person.roles[roleId=434].code

Somethings to figure out:

1. how to secure items that you created (i.e. you can edit the things you created)
2. related to above, securing specific items (i.e. role['application developer']). We may need to create permissions on the fly.

Actions

Each of the domains can have certain actions performed on them. These actions include:

• Create - For example, one may have permission to create new roles for a person.
• Read - One may have permission to read an attribute about a person.
• Update - One may have permission to update an attribute about a person.
• Remove - Remove an attribute, etc.

Chaining Permissions

Permissions should work such that the most specific permission wins. I.e. if viewing of all is blocked for everyone, but allowable for self, then when logged in, you can see your own address.

Specific permissions deals not only with the domain (i.e. roles* vs. roles['Application Developer']) but also in the ranking of actors (i.e. everyone is least specific, User/System is the most specific).

Propagating Permissions

Permissions, particularly READ permissions need to be propagated to downstream systems (such as LDAP) so that it can properly apply its ACLs. Any downstream system that receives BULK information from OR should be required to implement the required permissions schemes if it will then use that information in reports or for querying.

Permission Load Time

If performance permits, permissions should be loaded on every request. However, with the way the system will most likely be used, loading once per session may be acceptable. Changes to the permission model should be pushed out as quickly as possible, as with other changes to underlying data.

What Should Permissions Affect?

Permissions should affect everything related to the information. What does that mean?
1. It may limit the information you can see on the screen (i.e. you may not be able to see SSN).
2. It may limit the items you can choose (you may only be able to add select roles)
3. It may limit the information you can edit (you may be able to see SSN, but not change it).
4. It may limit the actions you can take (you may not be able to update a person, create a new person, etc.).

Association with SoRs

The OpenRegistry relies on the notion of a system of record for adding data to the system. There is not necessarily a one-to-one mapping of user to system-of-record, thus our system needs to take into account that a user may be associated with more than one system of record and that a system of record may have more than one user associated with it. Users may have permissions specific to a system of record.

In addition, users may have specific interfaces that they can access SoRs on. For example, we may limit the BATCH_STUDENT_USER to using the batch interface for the student system, while the U_REGISTRAR user may be able to update the information from the Web UI (for example).

Association with Calculated Attributes

Calculated values can only be changed by the OpenRegistry System, with the exception of certain identifiers, and "preferred" choices. Who or what can view the calculated tables must be controlled through permissions. These permissions must take into account existing federal, state, and local laws which may play severe limits on the visibility of data, and how it is propagated downstream.

Implementation

Representation of Rules/Permissions

Rules are represented using a standard language such as Unified EL or OGNL. This means that rules can be based off the normal JavaBean properties of a class. I.e. person.roles.addresses0.

Bundling of Rules

Some institutions or organizations may wish to apply common sets of rules to the majority of their users. Therefore, while individual rules MUST always be able to be defined, the underlying system MUST support the notion of bundling rules/permissions into rulesets/permissionsets.

Therefore, a user (or users), can either have a rule/permission or rule/permissionset attached to them.

Database Design

System of Record

Represents the system of records in the system.

User

System of Record <-> User Link

Permissions

PermissionSets

TODO mapping of users to permissionsets and permissions