You might remember my simple model of static objects of the corporation. Now here comes the complexity. In my nice a lean model of the static IAM objects there was one innocent and less impressive object called constraint.
I borrowed the term constraint from RBAC [1], where various kinds of constraints can be specified. RBAC knows separation of duty constrains, prerequisite constraints, and cardinality constraints. The constraints of the RBAC model are expressed using the Object constraint Language (OCL). OCL constraints, based on first-order logic, are generally perceived as being difficult to understand.
In this BLOG post I don't follow the narrow RBAC view of constraints. Let's step back first, to get a complete view of the privilege determining dimensions. If the question goes like this: "What are the dimensions of information, which determine the privileges (permissions) to be bundled to one role?" Then the answer might come as a list like this …
Therefore I bundled all other dimensions - except the business function - to the object constraint. But now it is time to unfold them and to name the different dimensions or types of constraints.
As a helpful notion, the three disciplines of AIM, IM (identity management), AM (access management) and CM (compliance management) can be clearly separated from each other's. Here, the AM resides on top of the IM and the CM on top of the AM. constraints hence are part of the AM; SoD's however belong to the CM (which deserve its own, or more, BLOG post).
Checks for the separation of duties are required in two cases:
After having done that the technicians may add references the technical permissions which may be provisioned to target systems or interpreted directly at run time.
I borrowed the term constraint from RBAC [1], where various kinds of constraints can be specified. RBAC knows separation of duty constrains, prerequisite constraints, and cardinality constraints. The constraints of the RBAC model are expressed using the Object constraint Language (OCL). OCL constraints, based on first-order logic, are generally perceived as being difficult to understand.
 |
| There are several privilege determining dimensions |
In this BLOG post I don't follow the narrow RBAC view of constraints. Let's step back first, to get a complete view of the privilege determining dimensions. If the question goes like this: "What are the dimensions of information, which determine the privileges (permissions) to be bundled to one role?" Then the answer might come as a list like this …
- Business function (as defined in a functional enterprise model),
- Region,
- Organizational unit,
- Market,
- Authorization amount limit
- Project,
- Information object
- Contract type
- …
Therefore I bundled all other dimensions - except the business function - to the object constraint. But now it is time to unfold them and to name the different dimensions or types of constraints.
The seven commonly used constraint types are:
- Region - usually the functions to be performed are limited to a region (US, Germany, Brazil, China ...). It may be useful to explicitly state the absence of this restriction by the introduction of a region "world".
- OU - quite often the areas of responsibility have been separated by the definition of organizational units (OU) already. This applies to markets on the top level such as banking, insurance and leasing as well as to executive secretaries (by business line) or to departmental activities. Again, it may be useful to make the absence of this restriction explicit by the introduction of the OE "group". Projects in this context can also be regarded as (temporary) OUs.
- Customer group - the segmentation of the market by customer group (wholesale, retail, corporate customers, dealers …) also leads to constraints to the pure function.
- Authority level - in order to control inherent process risks organizations often set "levels of authority". There may be directly applicable limits, which are expressed in currency units or indirectly applicable ones. In the latter case they are expressed in parameters such as mileage allowances, discounts, discretion in the conditions defining ... which in turn can be converted into monetary upper limits.
- Project - If projects are not considered as (temporary) OUs, they represent a
separate dimension determining information access: project managers and other project functions usually have received their privileges for a particular project and cannot access resources of other projects. - Object - Sometimes you may be able to restrict permissions to a defined information object. A tester has to run tests on particular software object (application or system) only; a janitor is responsible just for a particular house.
- Contract type - Different privileges also arise from the contractual agreement a person has with the corporation. Hence the permissions of permanent employees, interim managers, contractors, consultants and suppliers usually differ considerably.
Other conceivable constraint types are...
- Cost centre - sometimes cost centres don't match with OUs or projects and for reasons of cost allocation employees are allowed to "move" within their cost centre only.
- Company Code - To further fine structure market segmentation within customers groups or for the distribution of workload sometimes auxiliary structures such as client or company codes are used. Different codes may lead to in differing permissions.
- More to come - ... most probably there are more privilege-determining dimensions in use out there, which haven't been listed here.
Segregation of duties
Following the structure used above segregation of duties (SoD) do not count as constraints. They do not further restrict the privileges which are granted via assigned functions, but exclude certain functions form being combined. |
| IM + AM + CM |
As a helpful notion, the three disciplines of AIM, IM (identity management), AM (access management) and CM (compliance management) can be clearly separated from each other's. Here, the AM resides on top of the IM and the CM on top of the AM. constraints hence are part of the AM; SoD's however belong to the CM (which deserve its own, or more, BLOG post).
Checks for the separation of duties are required in two cases:
- When roles are created / modified to ensure that they are inherently free of SoD conflicts.
- When roles are combined, e.g. when assigning them to digital identities (persons) or when they are aggregated into combined types of roles.
Application
To determine the necessary permissions for a given job description, you need to determine …- Which of the above-mentioned constraint types are actually used to determine privileges,
- What possible additional constraint types can be detected by examining existing privilege assignments and
- Which values of these constraints lead to which privilege restriction?
After having done that the technicians may add references the technical permissions which may be provisioned to target systems or interpreted directly at run time.
[1] D.F. Ferraiolo, R. Sandhu, S. Gavrila, D. R. Kuhn, and R. Chandramouli. Proposed NIST Standard for Role-Based Access Control. ACM Transactions on Information and Systems Security, 4(3), August 2001.
Brilliant understanding made about constraint universe. thanks for this.
ReplyDeleteJob Duties
Thanks Jaylen, it would be rather interesting to know which other constraint types are in use out there in the wild.
DeleteIn the original NIST RBAC, a constraint meant the segregation of duties (SoD), i.e. which role-combinations were allowed and which were not.
ReplyDeleteThis 'constraint universe'-article lists a lot of other constraints than the segregation of duties, but the way these constraints are used (which values of these constraints lead to which privilege restriction) indicates that they are more like attributes - attached either to the user, his organization (i.e. principal) and/or to the user's permission.
Thus, a user's permission can be restricted to be valid in a certain country, for a certain group of customers (if external user, then this restriction should be dependent on power of attorneys), for certain projects, for certain cost centers, etc.
It's up to the access controllers (most often the applications) to interpret the 'constraining' attributes according to the applications' functional specification. Thus, an external user may have permission to 'external insurance policy administrator'-role and the permission is restricted to be valid only within US and only for certain line of businesses. The most common restricting attribute is the external user's customer id - so common that we even don't notify that it's an attribute.
And of course, the range of different attribute types is endless. In a centralized IdM, we should be able to create new attribute types, add new attribute values and also import attributes from existing legacy systems. Then, you are able to grant permissions and restrict them with all those attributes which are needed in the applications as they authorize users to confidential data.