objects, subjects & actions

As from a purely static picture we will never be able to derive the dynamics, i.e. processes, clearly time has come for some dynamic considerations.

Remembering the RBAC definition of permissions as ‘actions on objects’ we are clearly still missing that someone who performs these actions, the actors. Hence these special objects, which are able to act, turn into subjects:

In processes subjects (actors) act on objects.

Subjects may be users or managers

Managers are owners or clerks.

• Owners are responsible
• Clerks act on behalf of owners
• Owners delegate to clerks

Subjects act or react

• Their activity triggers an event
• Reactions often are decisions (like approvals)

What now is the difference between acting and reacting? Does any subject really act on its own discretion?

Keeping in mind that we only regard events triggered by subjects which are confined in the IAM system any action which are triggered by external events can be regarded as actions.

Follow-up actions whose events were triggered by preceding actions can be regarded as re-actions.

Time may act as a (virtual) subject

• Time acts on behalf of the organization
• Time triggers a predefined action
• The action is driven by a policy
• Time-triggered events are common

events

I mentioned the term ‘event’. Events trigger the dynamic, the make the system move.

• actions (and whole processes) are triggered by events.
• There are events …
• fired by embedding business processes.
• created by an subject
• triggered by time
• fired by state transitions

Events from outside the IAM system we call business events. Without business events there would be no need for the entire IAM system.

Request & approval

Let’s have a closer look to the action itself. What happens when an individual applies for access to an object? It requests access. In an abstract view a subject requests an object. As done before we can derive an object from this relationship: the ‘request’.

• The request is a transient object but it may well be persisted.
• It is the central workflow object found in IAM systems.
• It can be understood as the instantiation of a process type.
• The request is created by an event, e.g. …
• when a subject requests access to an object.
• when time has come to re-validate a role / privilege.
• when the defined response period has been passed without an activity (escalation)
• …

Who now approves a request? As a general rule the owner of the requested object has to decide whether to approve or to deny.

• The objects’ owner decides on the request
• Hereby he changes its state
• States are:
• new
• approved
• rejected
• escalated
• We can expect as many requests as there are object owners.

To make the situation even more complicated - objects owner may delegate the decision to someone else or activate a policy which acts on behalf of him following pre-defined rules.

Subjects decide on requests

Let’s summarize:

• In workflows subjects (actors) act on objects
• The acting subjects may be owners or a clerk
• Owners are responsible
• Clerks act on behalf of owners
• Owners delegate to clerks
• Owners may pre-define their decisions by activating policies.
• Subjects act or react
• Their activity triggers an event
• Reactions often are approvals

 

Every object has an owner

The guiding key concept is the concept of ownership, assigning the responsibility for an object to its owner:

• Each object as one owner
• The owner is responsible for the object
• The owner may delegate object management to a custodian.
• The owner may temporarily transfer ownership (full responsibility) to delegate.
• Owners differ considerably from one organization to another
• This apparent complexity is a result of customizing a simple model

In my next post I should try to identify elementary action which we later may use to compose IAM processes.

But before doing that I like to insert a few words on the modelling approach we use here: the ‘essential systems modeling’.

It therefore may be worth to stay tuned.