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 ResourcesAccording 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 organizationOnce 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.
5. The roleLet’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.
- a contract defines the relationship
- a role defines incarnation details
- the contract’s details then are expressed by several roles
6. Role vs. authorizationAt 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 pictureBy 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.
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.