Good morning! I’ve just discovered Cerbos and am considering it for upcoming work in my firm. So far, I’m very impressed. My question is largely focused on Principal/User management. Is there a way to tie Cerbos (or Cerbos Hub) into an existing external Users database, ie a Postgres table? We have thousands of users and it would be incredibly valuable to have new users automatically imported into Cerbos Hub with some default set of roles and/or attributes.

Hey @Peter McClonski! Glad to hear you are considering us! cerbie Cerbos is stateless by design which means it is not aware of the application data. The way it works is the application in question fetches the required information from the database, idp etc. and then composes a request consisting of

principal

,

resource

and

action

. Then the application sends the composed request to a Cerbos PDP instance, which in turn responds with whether the given

action

is allowed on the

resource

by the

principal

.

Right, so I guess my question would be, how can I ease population of my Principals in Cerbos? Is this just something where I'd have to, as part of my user registration process, create the principal through API calls?

I'm assuming in this case that a Cerbos Principal has a 1-to-1 equivalency with a single User in my application. If that's an incorrect assumption, I'd be interested in learning more.

Hey Peter 👋 . Cerbos does not store any principal data and you don’t need to populate or update anything. You pass the information Cerbos needs to know (principal, resource and action) to perform the check to Cerbos with each API call.

Okay, I think I understand. It sounds like I'm going to need to maintain a separate User database as part of my application which holds all the role info for each user, and all I need to do for Cerbos is populate my api request based on the data in my underlying store. While Cerbos doesn't care about individual users, it will take that combined set of roles for the given user, mapped against a particular resource, and give back an allow or deny for a given action. In other words, Cerbos holds a set of roles, and a set of resources, and a set of policies mapping those roles and resources to approved actions (ie, view). My application also holds the same set of resources, as well as the roles assigned to each user. The only thing Cerbos holds, which my application doesn't hold, is the policies and the logic to apply those policies.

The only thing Cerbos holds, which my application doesn’t hold, is the policies and the logic to apply those policies.

exactly 👌. This stateless approach makes sure our users don’t need to worry about keeping Cerbos up to date with actual principal and resource data.