Objects of the corporation

1. The User: Identity uses a Resource

In many corporations digital identities first pop up as users. It is a short form of expressing that the digital identity is tied to resources: It „uses“ resources. It does so by performing activities. This relation from the digital identity to the resource may carry attributes. It may be perceived as a derived object: the user. 

Another a synonym is account. But to be precise in terms of semantics it is more about the use rather than the user. 

In terms of the Access Management (AM) however it deems to be more appropriate to name the relationship “is authorized to use” and the resulting derived object “authorization”. 

2. The operation: authorization to operate on the resource

Users may be authorized to operate on resources: In other words: they are performing operations. This relation in turn may carry attributes. Again a derived object can be defined: the operation.

3. Permission = operations on Resources

According to the RBAC framework [Ferraiolo and Kuhn, 1992] operations on resources (objects) may be labeled with permissions. Permission is an approval of a mode of access to a resource. Sometimes permissions are called “entitlements”. More generally they are defined as “operations on objects” –just a different wording for “operations on resources”. 

4. The Identity belongs to an organization

Once we have referred to RABC the obvious need pops up to define another object: the role. Digital Identities don’t exist in isolation. In fact, if no one would be interested in its ID and / or its attributes. It wouldn’t make any sense to care much for a digital identity – unless it has a relationship to an organization: In a way the digital identity belongs to an organization as it plays a role there. There might be more than one elementary relationship – usually an agreement or a contract. And there are many possible specializations of this relationship. Again this relationship may carry attributes. And – not surprisingly - it turns to a derived object: the individual role. It might sound a bit academic but it is worthwhile to emphasize that a role characterizes a type of relationships:

• The role is a predefined class of a relationship a digital identity may have to an organization.
• When the role is assigned to a digital identity, parameters are set to form the authorization.

This type vs. actual discrimination turns out to be useful general modeling principle. There are many possible specializations of the relationship class role and its incarnation authorization. Examples are employees' contracts, freelancers' contracts, partner- or customer-contracts. Obviously more than one such relationship may exist at the same time: means a digital identity may be assigned several roles.

5. The role

Let’s explore the nature of roles a bit deeper. The role type obviously is an abstraction. It resembles very much the product which abstracts the contract. Keep in mind that the very justification of a product is to have a chunk of pre-built business which makes it easier to close a contract. Hence the role relates to the authorization like products to contracts. And the authorization looks similar to an employee contract. Let’s summarize:

• The product generalizes the contract. It is a contract type (aka product).
• The contract in turn instantiates the product (or contract type).
• The role generalizes the authorization.
• The authorization in turn instantiates the concept of a role.

Both may in fact be combined into one agreement. They also may as well be left separate for the ease of handling. Recognizing the close relationship between roles and contracts may help us finding appropriate roles by looking at the related contracts. If there is a contract there might as well be a role or more to be identified. If there are roles defined there must be at least one contract – regardless whether documented or not. Hence not only employees also customers, suppliers or any partners may receive roles as well. The role and the contract may well be one agreement (collapse to one). But for practical reasons we could give the contract a fine structure.

• a contract defines the relationship
• a role defines incarnation details
• the contract’s details then are expressed by several roles

6. Role vs. authorization

At our starting point we took the naïve approach of an individual (represented by its digital identity) uses resources and derived the use as the relationship object to contain the relevant information about the use. For our purpose we called it the authorization. Next we recognized that there was room for some abstraction. The role now carries all the abstract use. The instantiation of this role – we called it the authorization – has then to keep all the actual information: the link to the digital identity, to the role, start- and end-dates and the like.

7. The whole picture

By considering the identity’s relationship to two different objects – namely to the resource and to the organization we received two distinct branches which should belong to one tree.
Both have two objects in common: the identity and the authorization. Combining them however needs to rethink the reason for doing so. If the role abstracts the authorization it should be the role too who defines of the operations on the corporation’s resources. 

Meanwhile the whole picture has grown and became more complex. But it still is far from being complete. It is worth to have a closer look to the role as the way we use this concept here differs a bit from the common use in daily life. The role as we defined it here is expressed solely in business terms. That’s why some call it a business role. But in daily life, if we talk about the role some plays in a corporation, our perception is more one of the function person has for that particular corporation. So here the function is the role a person plays – so why not call it the functional role? Following this definition however we receive a role which is not information rich enough to contain all privilege determining dimension. If for example your functional role is to be a salesperson you may be restricted to a certain sales area or to a certain group of products. So there is something beyond the functional role constraining their full potential. Let’s call it the constraint for now – and go more into depth later. So we split up the “organization” into functional roles and constraints. 

More even the picture offered here still expresses the static relationships only. It still does not distinguish between objects and subjects (actors). And the concept of ownership still needs to be introduced.