A ECM System User Object Authorization Model

** System User Object Authorization Model

Revision History

:

Authorization is the maintenance of security permissions for users to get access to application resources and data. Authorization can be separated into two separate sections: System Authorization and Object Authorization.

System Authorization:

Each system has a set of functions or capabilities a user can take advantage of to fulfill their task. Each system capability is assigned a right. For instance, if the system allows scanning then there will be a “Scanning Right”. Each Right is the most basic and granular unit of the system function. If the system has an ability to review usage history and print a report about the history then there would be three distinct Rights associated with this. The first is “Access History Data”, the second “Generate History Report” and the third “Print History Report”.

A System Rights Profile (SRP) is a grouping of system rights and is definable by the system administrator (An SRP is similar to a system role). New SRPs can be created and assigned a set of Rights. Each user then can be assigned one or more SRPs.

1.1

When a single user is assigned multiple SRPs the user is granted a set of rights that is the union of all the SRPs. For example, there are three Rights 1, 2 and 3 and two Rights Profiles A and B where A is assigned rights 1 and 2 and B is assigned rights 2 and 3. If a user is assigned both rights profiles then they will have all three Rights.

Object Authorization:

Objects are anything that can be stored within the system. They can include documents, links, tree containers etc. Each object also belongs to one or more object groups. Object groups are public or private. Public object groups are definable and can be created or deleted by the administrator. Private object groups are associated with a user. For each user in the system a private object group exists with that user’s name.

As with System Rights there is a set of rights for objects stored within the system. Such rights can include seeing an object, opening it, copying it etc. Any action that can be associated with an object will have a corresponding Object Right. Object Rights can be grouped together into Permissions. The set of Rights in a permission is customizable. In this way the meaning of the “Update” permission is not hard coded but rather can be set by the system administrator.

An Object Rights Profile (ORP) is a set of permission associations to object groups. For example assume we have the object groups ‘memdata’, ‘loans’ and ‘reports’ and the permissions of ‘Read’ [R], ‘Create’ [C] and ‘Delete’ [D]. We can define a new ORP ‘Loan Officer’ as (memdata [R, C], loans [C] ).

Object permissions are assigned to users by either adding that user to an ORP or by assigning the user a permission to an object group directly. Users can be assigned to multiple ORPs. When a user is assigned to an ORP they receive all the permissions of that profile. The final set of rights a user has to an object is the union of all permissions assigned directly and through ORPs.

Since users can be added to multiple ORPs, a user may gain a permission from one even though the second ORP doesn’t include it. Normally the rights given to the user would be a union of the two ORPs. In the case that the administrator wants to ensure that anyone in the second ORP does not have a particular permission we need to be able to explicitly deny it. For this reason permissions can be assigned to an ORP or user as either ‘Allow’ or ‘Deny’. If a user is directly or inherently assigned a ‘Deny’ permission then they will be prevented from having access to it regardless of any other assignments.