https://cerbos.dev logo
Join Slack
Powered by
What's approach should I use to implement a policy...
# help
j
What's approach should I use to implement a policy that checks if a jwt has a specific claim with a specific value then allow full access to all data and services? Assuming I have a claim in a oidc idtoken called is_internal_user set to TRUE (it could also be blank for non-employees), assume further I don't need to verify the jwt against the well-known jwks endpoint of the token issuer (because this is already done by my api gateway for every REST api call to request for data), then should I write a derived role policy?
A derived role policy needs a parent role reference. But I don't understand why we need a parent role or how to define a parent role because my use case doesn't have a hierarchy of roles.
Furthermore, after I define a derived role policy, it looks like I then need conditions (https://docs.cerbos.dev/cerbos/latest/policies/conditions.html) that evaluate the derived role policy?
Is my understanding somewhat correct?
d
I will reply in 15 minutes
In a simple case you don’t need a derived role.
A parent role is a role defined in the request.
Your resource policy rule, checking the claim, may look like this
Copy code
- actions: ["view"]
  effect: EFFECT_ALLOW
  roles: ["user"]
  condition:
    match:
      expr: request.aux_data.jwt.is_internal_user == "TRUE"
Well, it might be a good idea to define a derived role `internal_user`:
Copy code
- name: internal_user
      parentRoles: ["user"]
      condition:
        match:
           expr: request.aux_data.jwt.is_internal_user == "TRUE"
So in other resource policies you can simply require a derived role 
internal_user
instead of checking this claim again.
c
assume further I don't need to verify the jwt against the well-known jwks endpoint of the token issuer
That depends on your risk profile. If you're absolutely sure that internal traffic can be trusted and there's no risk of replay attacks, you can disable JWT verification on the Cerbos end.
j
Jwt verification is currently done via the Api gateway. Internal traffic between the Api gateway and the rest api endpoints are controlled. Only the Api gateway is allowed to communicate with the rest api endpoints. All other traffic is being blocked. So I am trying to avoid adding additional latency to the Api call. @Charith (Cerbos)
@Dennis (Cerbos) what does parentRoles: ["user"] achieve?
Is there a default built in user in cerbos called "user"?
c
There are no built-in users or roles in Cerbos. We use the roles that you send in the request -- which we assume you have created in your user management system because it's very unusual to deal with individual users without any roles. If your system does not have any roles at all, you can make one up. That's what Dennis' example shows: he's assuming that there's a principal with a role named 
user
and then he created a derived role to codify the fact that 
internal_user
must also have a JWT field set to a particular value.
j
Aaaaah ok. So the role called "user" is passed as part of the json payload to cerbos' api (by my code / api being called) when evaluating an abac request, correct?
c
j
So in that URL, the principal "Alicia" is trying to "view" the resource type called "album:object" of which there is one instance called "XX125". Is this correct? @Charith (Cerbos)
Why is it a good idea to define a derived role? @Dennis (Cerbos)
c
So in that URL, the principal "Alicia" is trying to "view" the resource type called "album:object" of which there is one instance called "XX125". Is this correct?
Correct
Why is it a good idea to define a derived role?
So that you can define it once and reuse it in your policy rules. Then, if you ever want to change it, you only have to change it in one place and not on every policy file.
j
Thank you again, good sir!
🙇 1
So if I define the derived role of internal_user, this means when I write a policy, I can reference "internal_user", and when I call /api/check, do I need to specify the principal as being an internal_user or that is not needed because the jwt claim already has it. So with the jwt, cerbos knows automatically that this user has a derived role of internal_user, and it will find the correct policy to match the check request.
It sounds like the latter
And it sounds like derived roles are roles created on the fly based on rules.
So in the case of what Dennis wrote above the derived role called "internal_user" is a child of the "user" role. What is the significance of that? Does it mean the derived role will only be generated if the principal has a role of "user"?
- name: internal_user parentRoles: ["user"] condition: match: expr: request.aux_data.jwt.is_internal_user == "TRUE"
c
Yes, derived roles are computed on the fly based on the data in the request. It will look for the 
roles
in the request (referenced in the derived role as 
parentRoles
) and if that matches, it will evaluate the condition and if that returns a truth value as well, the derived role becomes "active"
So your incoming request to Cerbos must contain 
user
as one of the roles in 
principal.roles
field and a JWT with 
internal_user=TRUE
to activate the derived role definition above
j
Thank you!!!! Totally understand it now.
6 Views
Open in Slack
PreviousNext
Powered by