https://cerbos.dev logo
Join SlackCommunities
Powered by
I’ve been reviewing the docs at docs.cerbos.dev an...
# help
r
I’ve been reviewing the docs at docs.cerbos.dev and have a question or two. Is this the right channel for that? or another?
s
Sure! Go ahead.
r
Y’all prefer threading?
(I’m easy)
s
Umm, generally I prefer threading on public channels but avoid it in DMs 😄
r
gotcha.
It appears that 
derivedRoles
is how/where user-to-role definitions are defined and maintained. Is that correct?
e
Threading is cool, keeps the feed clean and topical. However, we are easy
yes, that is correct
r
I’d prefer to adjust to your norms 😉
OK. I’m thinking about how I’d implement Cerbos so I can evaluate it (running the existing container). Say I have an independent user service that is responsible for registering new users. Is the current thinking/pattern than on creating a new user, I’d write a new derived role object to Cerbos for that user?
That is, my user service does its work to create an account and also issues an API request to Cerbos to say “Here’s a new user with roles X,Y,Z…”
e
Re: user to role mapping: Cerbos does not maintain your user to role mapping. In each request, you can send us the user(principal) and the roles they are in in that object. Cerbos maintains a mapping and rules of actions to roles.
each request = when you wanna check if a user can do an action on a resource
for example take a look at this playground:
r
Ah yeah, the playground is a nice touch!
I walked through that before coming here.
e
You can see the policies on the left. and on the right, you can how each request would look like fro different users
So, when you have a new user in your ssystem, you’d know which role they are in. Therefore your request’s principal object would have all the info needed to make a decision
The only time you’d ping specific user info to Cerbos is when you have a principal policy. which is where the exceptional permissions can be taken care of
r
Right, that bit I’m clear on. I’m not clear on the pattern of teaching Cerbos that I have a new user/principal that has role mappings.
e
Cerbos does not need to know that.
r
I mean, I understand 
derivedRoles
to be the thing that defines those mappings
e
Cerbos does not maintain your user/role mappings
You’d do that in your LDAP/AuthN/Directory service
r
Hmm. I’m confused because I thought you confirmed about that 
derivedRoles
are where user-to-role definitions/mappings are managed.
Oh! But I think I grok what you’re saying.
before even issuing a request to Cerbos, I would have user context, including associated roles, that I’d use to send a request to Cerbos to check authorization
e
derivedRoles
is where LDAP role to Cerbos role mappings are maintained. BTW: You do not need the derived roles if you do not want to define a new role based on context. You can just use 
role
in the 
resourcePolicy
too
r
Much like when I log into a Unix host, my user and associated group memberships are part of the context of my session.
And any time I attempt to access a resource, that context is used to check against permissions (e.g. file perms)
e
that is a good comparison.
However, in Cerbos we can make those permission checks much more contextual (with evaluations of differnt attributes you can include in the objects)
Also, using those attributes, you can define new roles on the fly. For example:
• Your user role is 
manager
in LDAP
and there is no distinction between a manager in marketing department or sales department.
In Cerbos you can easily define a 
marketing_manager
derived role. Where parent role is 
manager
and 
request.principal.attr.department == 'MARKETING'
Then you can give permissions to 
marketing manager
in Cerbos policies. and as long as your 
request
principal
object has the 
attr.deparment
set correctly, everythign will work fine.
r
And that would work, as long as the request to Cerbos includes the 
department
property in the request body, correct?
e
correct
r
Gotcha. So there is no link between Cerbos and the directory. Cerbos entirely depends on the parameters of the request to be able to respond effectively (i.e. allow/deny).
e
If you have time, we’d love to get on a video call and better understand your use case, and also help you model your policies in our playground.
You are correct
r
I have 30 minutes now. Or 2 hours from 1300hrs - 1500hrs EDT
e
We decided to make it as standalone as possible so we can play with any AuthN/directory service out there. In the mean time we are working on better integrations with some.
r
otherwise, tomorrow morning (EDT)
I think that’s a reasonable approach.
I like the decoupling
Makes sense and is flexible.
e
6 Views
Open in Slack
PreviousNext
Powered by