tselect-npm/access-control

Simple, flexible and reliable access control for NodeJS and Typescript. Supports both RBAC and ABAC.

access-control's Issues

Fix vulnerabilities

PermissionEffect type conflict

In most of your examples, I see "effect: 'allow'" when creating a new permission. I.E

store
  .addPermissionToRole(Role.CUSTOMER, {
    id: 'CustomerCreatePostPolicy',
    effect: 'allow',
    resource: 'posts',
    action: 'create',
    condition: {
      stringEquals: {
        forAllValues: {
          bodyAttributes: ['title', 'content']
        }
      }
    }
  })

But when I'm coding, TypeScript gives an error since I am not using PermissionEffect.allow. I have created a working database interface(dynamodb) but it relies on strings mostly. Is there a way to add policies with "effect: string"?

Would this PR be welcomed here?

Worked on addressing onury/accesscontrol#93 for a while, and opened onury/accesscontrol#94 before realizing it was largely abandoned. Would that PR be approved here?

I read this repo is a fork of that repo, so hopefully it would not be too hard to include

Probably the cleanest repo i've ever seen. Love the use of emojis :)

Multiple conditions in one statement

It looks like the "condition" object in a statement (addPermissionToRole call) accepts multiple operators, and the operators are evaluated in an AND relationship. Can you confirm this is a valid usage?

Thoughts on a more official support of multiple conditions in one statement? Such as a "conditions" array? So multiple conditions with the same operator can be added?

forAllValuesIfExists doesn't pass for env value `null`

forAllValuesIfExists doc says:

This modifier does exactly the same thing as forAllValues expect that it ignores null/undefined values.

But it actually only recognizes undefined as non-exist value, not null. It passes for this case:

const condition = {
  stringEquals: {
    forAllValuesIfExists: {
      foo: ['bar', 'baz', 'boo']
    }
  }
};


const ok = {
  foo: undefined
}

const notOk = {
  foo: null // this doesn't pass based on my testing. I think it's a bug
}

The "condition-modifiers-manager.js" has a function:

    exists(value) {
        return !Lodash.isUndefined(value);
    }

It seems only undefined is recognized as "exists".

Better way to accept null values

We currently use the AWS way of handling null values in permission conditions (see https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_Null).

While this provides the expected functionality, it forces the consumers to duplicate their permissions in cases where null is one of the accepted values in addition to another type.

{
    id: 'WithString',
    condition: {
        stringEquals: {
            simpleValue: { foo: 'bar' }
        }
    }
}


{
    id: 'WithNull',
    condition: {
        null: {
            simpleValue: { foo: 'true' }
        }
    }
}

Instead, we would like to find a more elegant solution that would consumers to express the previous 2 conditions as a single "string OR null" statement.

Dependencies due for update

Mainly there is a high severity vulnerability in Lodash that had been fixed in 4.17.12.

lodash version bump?

Any chance of getting the lodash version bumped in @bluejay/access-control, @bluejay/collection, and @bluejay/utils so that I don't have to get npm audit complaints every time I add a module? 😄

lodash  <4.17.19
Prototype Pollution - https://npmjs.com/advisories/1523
fix available via `npm audit fix --force`
Will install @bluejay/[email protected], which is a breaking change
node_modules/@bluejay/access-control/node_modules/lodash
node_modules/@bluejay/collection/node_modules/lodash
node_modules/@bluejay/utils/node_modules/lodash
  @bluejay/access-control  2.5.2 - 2.6.4
  Depends on vulnerable versions of @bluejay/collection
  Depends on vulnerable versions of lodash
  node_modules/@bluejay/access-control
  @bluejay/collection  4.2.8 - 4.3.6
  Depends on vulnerable versions of lodash
  node_modules/@bluejay/collection
    @bluejay/utils  3.5.1 - 4.0.0-alpha.0
    Depends on vulnerable versions of @bluejay/collection
    Depends on vulnerable versions of lodash
    node_modules/@bluejay/utils

Attach more data besides returnedAttributes to permissions

In my understanding, the "returnedAttributes" is basically a piece of custom data that can be attached to a permission statement. And it can be retrieved if the permission statement is used to grant a subject to access a resource.

Is there a way to attach more custom data besides the "returnedAttributes" attribute to permission? There are other cases besides the "returnedAttributes" case.

For example, if a user can only see books published in his own country, we might want to attach a "where books.country = user.country" condition when listing books for a user. It would be good to define this condition (and potentially other more complicated conditions) on the permission to grant user read permission to the "book" resource, and retrieve these conditions when listing books.

Such additional info on a "Permission" doesn't fit in the "returnedAttributes" concept, but can be useful.

Multiple to Multiple condition

Sorry for raising a lot of questions. We are seriously using this package :)

I have a use case to verify if an array-type subject attribute and an array-type resource attribute has any overlap. Looking to see what is the best way to achieve it with access-control.

For example: iPhone's TouchID fingerprints. Each person has 10 fingerprints, and each phone can remember 5 fingerprints.

So I was hoping to write a rule like:

{
  id: 'unlock',
  action: 'unlock',
  resource: 'phone',
  condition:  {
      arrayOverlap: {
        simpleValue: { 'user.fingerprints': '{{{phone.fingerprints}}}' }
      }
}

Here the arrayOverlap operator doesn't exist.

I wonder how you see this can be solved, or if it's valuable to add a few array-based operators.

NPM detected vulnerability

npm reports this issue now

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low           │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ braces                                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=2.3.1                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ @bluejay/access-control                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ @bluejay/access-control > filter-object > filter-values >    │
│               │ is-match > micromatch > braces                               │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/786                             │
└───────────────┴──────────────────────────────────────────────────────────────┘

Value Associated with Role?

First off, thanks for this library - it is exactly what I was looking for, and has excellent documentation.

I'm trying to figure out if there's a way to associate a value with a role. For example, in the system I'm working on, a user can have different privileges for different organizations, so I'd like to be able to say something like: `addRoleToSubject(subject, roles.ORGADMIN, organizationId), and then build my policies appropriately.

Any suggestions?

Validate resource in addPermissionToRole

When calling addPermissionToRole, if one of the resources is undefined, it would lead to an error

TypeError: Cannot read property 'split' of undefined
      at AccessAuthorizer.filterRelevantPermissions (node_modules/@bluejay/access-control/src/classes/access-authorizer.js:60:62)
      at AccessAuthorizer.authorize (node_modules/@bluejay/access-control/src/classes/access-authorizer.js:21:42)
      at AccessControl.<anonymous> (node_modules/@bluejay/access-control/src/classes/access-control.js:20:42)

You should be able to reproduce by codes like this:

store.addPermissionToRole('some_role', {
    id: 'read',
    effect: PermissionEffect.ALLOW,
    resource: [undefined],
    action: ['read']
  });

Extending Roles?

Thoughts on supporting extending roles? It's a common case when a role's permission is a superset of another role. https://www.npmjs.com/package/accesscontrol supports role extension, so I wonder if this project plans to support it, too.

We could also add multiple roles to one subject if that's the suggested way to do it.

forAnyValueIfExists should pass if environment doesn't have the key

See the ok2 condition below. Please let me know if you agree.

const condition = {
  stringEquals: {
    forAnyValueIfExists: {
      foo: ['bar', 'baz', 'boo']
    }
  }
};


const ok = {
  foo: ['bar', 'booz', undefined] // This will pass because bar is an accepted value
};

const ok2 = {
  foo: undefined  // This should pass for the same logic as simpleValueIfExists. Currently, this doesn't pass
};

In the use case I have, sometimes the env has a groupId that needs to be matched against a list of IDs to see if it matches any of them. Sometimes the env doesn't have this groupId attribute and it should allow (condition match) in this case.

Can't install this from yarn

Trying to install throws FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
I think it's because you have circular dependency between @bluejay/collection and @bluejay/utils

No Doc for Persistence Layer

In the Readme there is this lines

We'll then need to tell Bluejay where to look for permissions. AccessControl comes package with a built-in MemoryStore that allows you to manage permissions in memory. We'll cover persistent stores later in this documentation.

But it not anywhere in the docs. Please help thanks. MongoDB Layer will be helpful

Keys.filter() will not filter out an object property that equals an empty object.

I'm working with a codebase that is using Objection.js to create database models from a Postgres DB. The model in question has a property represented in the DB as a JSONB not null data type, so we anticipate that when we run a query returning a row where this column is an empty JSON object, we'll get something like model.jsonColumn = {}.

I noticed that when I try to either run a Keys.filter(model, ['!jsonColumn']) blacklist or do not include jsonColumn in my whitelist, the jsonColumn value still displays with the empty object. I've played around with manipulating the properties of our model, and I've noticed that the filtering does work when I wrap the JSON.stringify method around the column, i.e. model.jsonColumn = JSON.stringify(model.jsonColumn).

I'm wondering if it would make sense to update the Keys.filter to handle properties whose values are empty objects as a quality-of-life improvement. Would love to hear your thoughts, and thanks for this library!

Suggestions: Hierarchical Role Based Access Control & more...

Hi,

I am currently looking for a great JS lib to handle 'Hierarchical Role Based Access Control' or 'HRBAC' and the ones I've found are not so pretty as yours.

1. Do you have plans to support it in the near future ?
2. Do you have any suggestions/workarounds to handle hierarchy in the most efficient way with current version ?

As another suggestion, that would be great to be able to mix exclusion and inclusion in returnedAttributes with priority for exclusions by default (configurable maybe ?)

Also, maybe allowing condition to be a simple function resolving to true/false could be easier in some cases.

Anyway, thanks for your work.