This use case happens in many different industries, such as:

  • Banking: account management

  • Healthcare: medical record access

There are other types of delegation possible, e.g. a parent-child delegation. For instance, as a parent, I want access to my underage children’s medical records. This is akin to power-of-attorney rules in the real world.

There is yet another type of delegation, albeit an indirect one, which takes place in extraordinary circumstances. Imagine an insurance use case where agents process claims based on the region they are in. If a region is hit with a flash flood, that region will have more claims to process, and the agents there may want to delegate access to their claims to other agents.

All these use cases follow the proxy-delegate pattern. There is a user who can act as a proxy for another (I, the parent, act as a proxy for my child) or as a delegate of another person (I, the doctor have been delegated access).

Implementing access delegation
A finance ABAC scenario

XACML, the eXtensible Access Control Markup Language, is a great language to implement Attribute Based Access Control (ABAC) scenarios. For instance, with XACML, one can easily implement the following scenario:

  • Managers can approve a transaction up to their approval limit.

In this example, we have:

  • 2 subject attributes: the user’s role (manager) and the user’s approval limit.

  • 1 action attribute: the action value itself (approve)

  • 2 resource attributes: the object type (transaction) and the amount of the transaction.

The scenario can be rewritten as an attribute-based policy:

  • A user with the role == manager can do the action == approve on an object of type == transaction if the transaction’s amount ≤  the user’s approval limit.

The vacation policy

In any delegation, we need to define the baseline:

  • Managers can approve a transaction up to their approval limit for customers they have a relationship with.

  • Managers can view the accounts of customers they have a relationship with.

We can then add the delegation scenario. In the case of a vacation, we would add one attribute:

  • The delegate attribute: this is an attribute of the subject. Given a user identifier, look up the list of delegates that user has defined.

The policy is now rewritten as:

  • Managers or delegates of the given manager can approve a transaction up to their approval limit for customers their have a relationship with.

Now, of course, users are not always on vacation. This means that the delegation should not always work. In other words, we need another attribute to limit the time scope of the delegation. There are two ways to do this:

  • Introduce a flag called delegationActive or isAway. This boolean attribute determines whether the original user – the manager – is away.

  • Introduce 2 time attributes e.g. awayStart and awayEnd.

The policy can now be rewritten as:

  • Managers or (delegates of the given manager when isAway == true) can approve a transaction up to their approval limit for customers they have a relationship with.

The policy in ALFA would become:

/**
* Control access to transactions
*/
policyset transaction{
target clause object.objectType == "transaction"
apply firstApplicable
/**
* Approve transactions
*/
policy approveTransactions{
target clause action.actionId == "approve"
apply firstApplicable
/**
* Managers can approve transactions for their clients
*/
rule managers{
target clause user.role == "manager"
permit condition stringIsIn(stringOneAndOnly(transaction customerId), user.assignedCustomers)
}
/**
* A user can approve a transaction if they have been delgated access
*/
rule delegates{
target clause isAway == true
permit
condition stringIsIn(stringOneAndOnly(user.username), delegates)
}
}
}
 
The guardian policy

Another example of delegation is the guardian policy. This is a use case most often seen in medical scenarios, although it generally applies to any consumer-facing industries (medical, banking, and insurance). Let’s take a baseline policy:

  • A user can view their own account.

The guardian policy would require an additional attribute:

  • A guardian attribute (or delegate)

The policy then becomes:

  • A user can view an account they own or an account that belongs to a user they are a guardian for.

In ALFA, this becomes:

policy account{ 
target clause object.objectType == "account"
apply firstApplicable
rule viewAccount{
target clause action.actionId == "view"
condition (user.username == account.owner) ||
(stringIsIn(stringOneAndOnly(user.username),owner.guardians))
}
}
 
The emergency policy

A final case of delegation is indirect delegation. As previously stated, this happens in the case of an emergency. The baseline rule would be:

  • An agent can process claims in their own region

The new rule would be

  • An agent can process a claim in a region if the region is marked as emergency

This means there is a need for a new attribute:

  • isEmergency: this attribute is associated to the region the claim belongs to

The combined policy becomes:

  • An agent can process a claim if it is in the same region as the user, or if the region is in an emergency state.

In ALFA, this becomes:

policy processClaim{ 
target clause user.role == "manager" and action.actionId == "process" and object.objectType == "claim"
apply firstApplicable
rule sameRegion{
permit
condition user.region == claim.region
}
rule emergencyRegion{
target clause region.isEmergency == true
permit
}
}
Conclusion

Attribute Based Access Control and XACML are powerful enough to express many different scenarios. This Question of the Week covered different types of access delegation:

  • Temporary delegation (also known as the vacation policy)

  • Guardian-Dependent delegation (also know as the parent-child policy)

  • Emergency delegation: in the case when an unusual activity requires that regular access control checks be ignored

There are probably other cases out there. Can you think of one? If so, tweet us @axiomatics.

 

The “Question of the Week” – an ongoing feature that will tackle technical and usage questions. We’ll have input from our sales engineers and customer relations teams. If you have a question to consider, please send it to webinfo@axiomatics.com.



Leave a Reply

Your email address will not be published. Required fields are marked *