https://authzed.com logo
Join Discord
Powered by
Discretionary roles
# spicedb
s
Bringing this Q here at Joseph Schorr's suggestion. We have an application where we would like some roles to be discretionary. We mostly want users operating in a "base" role, but if they are also (in our specific case) a board member, we want them to be able to activate the additional authority and access rights that go with being a board member on a discretionary basis. It's not a serious security distinction, but it's a useful way to avoid fat-fingering things. There are a bunch of similarly discretionary roles, but if we can model one we can probably model the rest. First question is: what's a good way to model this? Second question: how does that model change if we want it to be session specific? If I enable my "board" role on my phone, it shouldn't get enabled on the desktop I left logged in at home!
Migrating this to a thread to keep the responses gathered together.
j
define 
discretionary
in this case: is it truly temporary or a long-term-but-revocable?
s
Depends on your definition of long term. I wouldn't expect one of these roles to remain active for more than an hour or two at a time because users walk away from their machines.
I'm only just now getting started with ReBAC. I think you're proposeing a new, discretionary relation? Presumably adding entries would be authorized by something like a "durable" relation that is enough to authorize the enable but not enough to convey permissions transitively by way of the durable relation?
y
if it's a temporary elevation kind of thing, and it's time-bound rather than bound by another process, then having a relation that carries an expiration and enables the new access should be sufficient
but it'd help to know what the relevant parts of the schema look like (or a guess/with placeholders anyway). could you put together a playground share?
j
anything longer than "seconds" is long term in ReBAC 🙂
if it is based on the session, you can assign the role to a session, rather than the user itself
s
I had already planned to message with "let me get my head around the modeling language and see if I can pull together an example", so I think we're all heading down the same trail here.
j
and we have an AI assistant on the right side you can use to ask for further changes, if you prefer that over asking us here 🙂
s
A session, for us is more or less a particular user on a particular client device. We want a role election to be scoped by its session, so that seems like a plausible place to enable/disable/attach a discretionary roll. The roles in mind here are roll-up sorts of things
j
yeah, I did that in ^
I granted a time-bound session role vs to the user
s
Playground seems good. Probably more useful if I put in the time to learn something about the modeling language. 🙂
j
if you have any questions, feel free to ask us or ask the assistant
s
I think I get the gist of what you put together, It's certainly a close start. I'm still working on switching my brain from roles to relations.
In my current half-a%%ed effort, we don't really distinguish users. I was starting from Postgres roles. In that framing sessions are role-like and become members of their users, and all access decisions then derive from the set of roles active on a given session. Sessions are device-specific by construction, so we don't have to model that part explicitly. Sessions have an expiration of ~8 hours, but expiration can be extended if session is in active use.
Not advocating that design, especially. Just trying to express where we were at.
Last Q before I go read. I'm inferring from your sketch that we end up adding or removing tuples from one of these relations in response to enable/disable decisions? If that's the essence of it, then I think I see the shape of it and I need to go start building a first sketch of the relations.
Thank you, @Joey. But help.
j
> I'm inferring from your sketch that we end up adding or removing tuples from one of these relations in response to enable/disable decisions?
yes
you'd write/delete relationships (tuples) when roles/access changes
> Sessions have an expiration of ~8 hours, but expiration can be extended if session is in active use. you can push the expiration
you can have a session live under a user, if you like
grant the role/access to the user, but then check the session
but that's only necessary if you need that linkage
8 Views
PreviousNext
Powered by