ABAC PIP Attributes Request

2
votes

How shall PIPs resolve correct attribute values? Which kind of interface should it have to be able to resolve the attribute value? For example, I need to get user roles and in this case I just need to pass an attribute for the user id. Let's now make this task more complicated. What if I have context under which user role might be changed, so a single user id is not enough here. In this case, I need to pass the access level for which we are trying to get the user role.

So on this example we can see, that interface will change every time, and the only suitable one will be that accepts everything.

How are PIP usually implemented in this case?

Update

Example: We have the following hierarchy:

Level 0           1          2
Organization < tenants < documents.

Symbol < means right is a child of the left operand.

User might have role admin or user on each level. If user has admin role on level n then he is able to access anything on this level and level n+1,n+2,n+3.... In the same time user will have role user on all levels n-1, n-2, n-3....

Example:

    user        admin      admin
Organization < tenants < documents

This is the first part. The second part of it is about documents. Let's say, we have a few attributes such as publicTenant and publicDocument. Resolution of each other on different levels are not relevant and also requires knowledge not only of the userId but also the level on which we are working and resource attributes like organizationId, tenantId and documentId to resolve correctly not only role of the user, but also resource attributes.

How can this be implemented correctly in ABAC? Current solution is hybrid with ACL/RBAC/ABAC. ACL and RBAC are hidden under ABAC and used as attributes of subject, but this doesn't feel right.

1
securityxacmlabac
Hi, I'm also trying to some clarification around this question too. When you say user role might change, do you mean like "junior engineer is promoted to senior role?" - let's assume these two titles have different roles for all intensive purposes. And when you say access level is that like a clearance/classification level? Like junior engineer with secret clearance wants to access secret level document? – Michael C Good
@MichaelCGood, I've updated post with example. – QuestionAndAnswer
You say: Current solution is hybrid with ACL/RBAC/ABAC. Do you mean you know such solution? Can you describe it? If you do, there is a good chance we can translate it to pure ABAC. As a matter of fact, ACL is usually so simple compared to ABAC frameworks (like XACML) that it is considered a subset (particular use case) of ABAC. Same thing for RBAC0 and RBAC1. So in most cases, ACL/RBAC/ABAC = ABAC. Of course, you still need some identity/access management system for the user-role assignments, and you will need PIP(s) indeed to integrate your ABAC PDP with it. – cdan
@CyrilDangerville, So, ACL/RBAC/ABAC solution is indeed equal to ABAC. What I meant here, is all ACL and RBAC properties are expressed in ABAC attributes. For example, in ABAC attribute subject.role calculated out of ACL where role is actually lives. For subject.permissions we are unwrapping subject.role and getting role's permissions. Like, it doesn't feel really good, but better if I would manage them separately instead of single ABAC interface. – QuestionAndAnswer
OK. Another question for clarification: in your example, when you define the admin and user roles on tenants, do you mean at the level of each tenant? E.g. a person may have admin role on tenant A but only user role on tenant B. Same question for documents. A person may have admin role on document A but user role on document B? – cdan

1 Answers

1
votes

The following approach is based on XACML model. If you need a solution that better handle cases where some of the resource attributes are missing from requests, let us know. I can update my answer, but the solution is more complex since it adds more checks for empty/undefined attributes.

I use a simplified syntax but you can easily translate to XACML with these few conventions:

  • If the Target is not mentioned for a Policy(Set) or Rule, it means it is empty (applies to any request).
  • In the example, predicates like if attribute x = 'XXX' translate to a XACML Target /AnyOf/AllOf/Match with MatchId='string-equal', AttributeValue 'XXX' and the corresponding AttributeDesignator for attribute x.
  • Subject (resp. resource) attribute identifiers are prefixed with subject. (resp. resource.).
  • The policy/rule combining algorithm is implicitly set to deny-unless-permit everywhere.

The PolicySet would look like this:

  • PolicySet 'root'

    • Policy 'Organization Level'

      • Rule 'Admin Role': Permit if subject.organization-level-role = 'Admin'
      • Rule 'User Role': Permit if subject.organization-level-role = 'User' and ... other conditions to restrict what the User role can do at organization level ... (if too complex to fit in a Rule, you can change these Rules to Policies and the enclosing Policy to a PolicySet)

    • Policy 'Tenant Level'

      • Rule 'Admin Role': Permit if subject.tenant-level-role = 'Admin'
      • Rule 'User Role': Permit if subject.tenant-level-role = 'User' and ... other conditions to restrict what the User role can do at tenant level ... (if too complex to fit in a Rule, you can change these Rules to Policies and the enclosing Policy to a PolicySet)

    • Policy 'Document level'

      • Rule 'Admin Role': Permit if subject.document-level-role = 'Admin'
      • Rule 'User Role': Permit if subject.document-level-role = 'User' and ... other conditions to restrict what the User role can do at document level ...

For this to work, you would need to implement one or more PIPs to resolve the following subject attributes (you could do everything in one PIP, especially if all the user roles are managed by the same system, it's up to you):

  • subject.organization-level-role: organization-level subject roles; to get this, the PIP requires the following attributes as input: subject.userId, resource.organizationId
  • subject.tenant-level-role: tenant-level subject roles; to get this, the PIP requires the following attributes as input: subject.userId, resource.organizationId, resource.tenantId
  • subject.document-level-role: document-level subject roles; to get this, the PIP requires the following attributes as input: subject.userId, resource.organizationId, resource.tenantId, resource.documentId.

A few comments on the PIP implementation:

  • The PIP(s) may return an empty bag for each of these, if the subject does not have any role assigned at the corresponding level.
  • If the cost to fetch the user roles from the role management system is high, the PIP could be optimized by getting all of them at once (at all levels) from the role management system, the first time one of the subject attributes above is requested during the policy evaluation, then keep it in cache, and return from cache when another one of these subject attributes is requested. A lot of caching optimizations is possible here.