accesscontrol
accesscontrol copied to clipboard
Add environments and object conditions
pls see: https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-162.pdf page 8
pls add in version 3 "Access Control Mechanism evaluates a) Rules, b) Subject Attributes, c) Object Attributes, and d) Environment Conditions to compute a decision"
Thanks. Pls give me some details on what specific features (under env/subject/object.. control) your use case(s) require.
I'm trying to be careful with a few things that somewhat affect these kinds of design decisions;
- Embrace SRP. This library should do one thing and do that good.
- Avoid tight coupling with other systems such as OS, databases, other frameworks, etc.. (But these can be supported optionally)
- Friendly APIs, good semantics.
- Avoid unnecessary complexity.
Soon, I'll write a detailed overview on new or additional concepts/features I'm considering (to be implemented) which include partial environment control, date/time, rate controls, resource hierarchy, etc..
@onury I would have same interest as @mattmeye
My usecase would need the extension of passing in an object being validated. On a multi-tenant self-register system the users would be part of a scope
- in my usecase clubs or teams. I haven't found a way to do this in accesscontrol yet. Or did I miss it somewhere in the docs?
I would look for:
- user is admin of
Team A
inClub A
- user is coach of
Team B
in Club A - user is admin of
Club A
- user is admin of
Club B
@onury I would have same interest as @mattmeye
My usecase would need the extension of passing in an object being validated. On a multi-tenant self-register system the users would be part of a
scope
- in my usecase clubs or teams. I haven't found a way to do this in accesscontrol yet. Or did I miss it somewhere in the docs?I would look for:
- user is admin of
Team A
inClub A
- user is coach of
Team B
in Club A- user is admin of
Club A
- user is admin of
Club B
I have the same question. My case would be a user who is an admin within his own group, but should not have "admin privileges in others. I'm looking at a potential solution:
- adding a .where(),
ac.grant('group_leader').create('resource').where('resource', ['group_name=@self'])
const permission = ac.can('user').setScope({group_name: "group1"}).create('resource');
I find the createOwn and createAny (own vs any), a false dichotomy at times as there are cases for scope.
turn out someone has already built that in a separate module https://www.npmjs.com/package/accesscontrol-plus,
I think we can closed this