Business layer

Do you remember the company “Business Layers”? It was among the 1st who implemented a user provisioning software, called “day one”. What a perfect name for a company! Expressing their very business purpose - to promote privilege assignment from the technical level one level up to the business layer – in their corporate name. But later they successfully sold to Netegrity who successfully sold to CA who put all into a big melting pot and not much of the original ideas and products remained.

Last Sunday while jogging though the quiet very early morning Hamburg this company came into my mind again when I was suddenly missing – well – the business layer.
To explain it a bit more in-depth let’s have a look at the NIST original RBAC definition:

(Source: Ferraiolo, Sandhu, Gavrila: A Proposed Standard for Role-Based Access Control, 2000)

 

Here the roles are introduced as an abstraction of the users who might be – no, typically are – different individuals whereas the role, which is tied to a list of resources, might stay unchanged. Hereby the role factors out the commonality of the individuals with respect to the permission assignment. As the RABAC concept is widely known and even mostly understood there is no need to further explain, that roles can be assigned temporarily on session basis and can themselves be ordered in a hierarchy. Permissions by RBAC are defined as ‘operations on objects’, equivalent to ‘actions on resources’ and so on.

These resources however are the real physical resources. So they are not ERP-system or ERP-system.general_ledger or or ERP-system.general_ledger.accounts_payable but SAP FI or JD Edwards EnterpriseOne.GL or Microsoft Dynamics NAV.genel.accpay. Whereas the corporation on the business layer simply has defined that this role should have read-/write-access to the accounts payables.

So at this side of the equation an abstraction is missing too. Like the role abstracts the individual (represented by the digital identity) some ‘generic resource’ should abstract the ‘real physical resource’. By this intermediate layer we could reduce the necessary number of roles and hence reduce overall complexity.
And allow business people to model roles on the business layer.

O.K., how now should we call this new object? Generic object, virtual object, abstract object? Hmmm … but what is your opinion? Can you eventually follow and agree to my esoteric thoughts?

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.