CODEWITHSUNDEEP
javascriptspring-securityauthorizationkeycloakkeycloak-services
Tatha
Tatha

Reputation: 1293

Keycloak ABAC based policy enforcer without adding the attribute in token

I am trying to set up keycloak based ABAC, Attribute-based access control for my APIs. I was able to set it up creating a javascript based policy which looks for specific user attribute and then grant access, something like 

var context = $evaluation.getContext();
var identity = context.getIdentity();
var attributes = identity.getAttributes();
var privileges = attributes.containsValue('userAttributeFlag','Y');
if (privileges) {
    $evaluation.grant();
}else{
    $evaluation.deny();
}

This was only possible when the attribute, userAttributeFlag was added as a user attribute mapper for the client, so that the same is added in the access token

enter image description here

My question is, is it always necessary to add the attribute in the access token for the ABAC javascript policies to work. The problem with adding that to the token is if we have a lot of attributes that will unnecessarily increase the size of the token which we would like to avoid.

In the mapper, there are options to added the attribute to the userInfo, but is it possible to evaluate that through a javascript based policy.

Thanks for any help.

Upvotes: 2

Views: 3326

Answers (1)

David Brossard
David Brossard

Reputation: 13834

To me it sounds like you are using Keycloak's ABAC to implement permission-based AC or RBAC. True ABAC assumes a (relatively) small set of attributes about the user and a set of resource attributes e.g. user department and resource department. In that case you have a policy that grants or denies access based on those attributes.

For instance an ALFA policy would look like:

namespace example{
   policy example{
      apply firstApplicable
      rule allowSameDepartment{
         permit
         condition user.department == doc.department
      }
   }
}

In your case, it seems like your code is doing the check. this forces you to create more user attributes to achieve the granularity. And that leads to token bloat. This is an issue that is common to all token-based / identity-based authorization schemes. It was true of SAML. It's true of JWT.

Upvotes: 2

Related Questions