Add environments and object conditions

[mattmeye]

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"

[onury]

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..

[dohomi]

@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 in Club A
• user is coach of Team B in Club A
• user is admin of Club A
• user is admin of Club B

[rexfng]

@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 in Club 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:

1) 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.

[rexfng]

turn out someone has already built that in a separate module https://www.npmjs.com/package/accesscontrol-plus,

I think we can closed this