Extending Roles?

[tselect-npm]

Extending Roles?

[SylvainEstevez]

@broom9 We could definitely consider adding role inheritance. If you have ideas on how this could be implemented, then feel free to share them here and we'll see how we can make things happen.

As of today, and as a you mentioned in your issue, adding multiple roles is indeed the way to go with the current implementation. If you're using the builtin memory store, then it will take care of fetching permissions for all roles the user is assigned to and evaluate permissions associated with each of those roles.

On another note and to better understand your use case, which of RBAC or ABAC do you need?

[broom9]

Thanks for the quick reply. In my use cases, I'm fine with making each role "small" and assigning each user multiple roles. Essentially it's a role composition instead of inheritance. So role extension is not a big requirement for me. Just wanted to confirm the recommended way of handling. We’re using a mixture of RBAC and ABAC, I think. There are notions of roles in the system. But we also need to rely on attributes on subjects and resources to authorize. The main use case is regular users can only see/operate resources they “own”, which takes a check of whether resource.userId equals req.user.id <http://req.user.id/>. Another one is all users can only query resources within their tenant because it’s a multi-tenant system. It would be great if we can add some example or explanation on how to implement this kind of use case. The condition statements plus variable seems like the function I need, but I haven’t verified yet.

…

-- Wei Wei

On Jan 17, 2019, at 04:53, Sylvain ESTEVEZ ***@***.*** ***@***.***>> wrote: @broom9 <https://github.com/broom9> We could definitely consider adding role inheritance. If you have ideas on how this could be implemented, then feel free to share them here and we'll see how we can make things happen. As of today, and as a you mentioned in your issue, adding multiple roles is indeed the way to go with the current implementation. If you're using the builtin memory store, then it will take care of fetching permissions for all roles the user is assigned to and evaluate permissions associated with each of those roles. On another note and to better understand your use case, which of RBAC or ABAC do you need? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABu1ADcjUyYsQzYA98XsR5tfgaktZVzks5vEEgAgaJpZM4aD22c>.

[SylvainEstevez]

Reading your explanations, conditions with dynamic variables indeed seem to fit your needs. I'm trying to provide some examples below, let me know if things are not clear enough.

Ensuring that resource.userId == req.user.id

Assuming an endpoint GET /profiles/:user_id that allows users to fetch profile information. To ensure that the user only accesses their own information, you could write a permission like this:

const permission = {
  id: 'UserFetchProfile',
  resource: 'profiles',
  action: 'fetch',
  effect: 'allow',
  condition: {
    stringEquals: {
      simpleValue: {
        'req.params.user_id': '{{{subject.id}}}'
      }
    }
  }
};

Then to check the user's permissions:

const subject = new Subject(req.user);
accessControl.authorize(subject, 'profiles', 'fetch', { req }); // <- Passing req to the environment

Ensuring that users only reach the tenant they're allowed to

Gonna assume that you're storing something like a tenant_id property within your user data and that you're able to access the tenant's id from the url in your request. We can modify the condition as follows to add the constraint.

const permission = {
  id: 'UserFetchProfile',
  resource: 'profiles',
  action: 'fetch',
  effect: 'allow',
  condition: {
    stringEquals: {
      simpleValue: {
        'req.params.user_id': '{{{subject.id}}}',
        'tenant': '{{{subject.tenant_id}}}'
      }
    }
  }
};

Then to check the user's permissions:

const subject = new Subject(req.user); // <- Where req.user.tenant_id is defined
const tenant = parseTenant(req); // <- Your way to parse the tenant information
accessControl.authorize(subject, 'profiles', 'fetch', { req, tenant }); // <- Passing req and "tenant" to the environment

This will guarantee that the user can only fetch their own profile on their assigned tenant.

---

If what you are looking for is a way to factorize the tenant check for all users, then I'm afraid it could only be done with condition merging, which is a bit different from role inheritance and would probably be hard to implement. I'm definitely open to suggestions on how to handle this though. Hope that clarifies things a bit!

[broom9]

Thanks for the detailed example codes. There is still one thing I'm not sure it's clear.

When you delcare simpleValue condition like this:

 simpleValue: {
        'req.params.user_id': '{{{subject.id}}}'
      }

The key 'req.params.user_id' is retrieved from the environment, basically the package will try to do environment.req.params.user_id, which makes sense.

Does the value subject.id need to be in the environment as well? I thought it would use the subject parameter passed into the authorize method, but from my experiment looks like it needs me to pass "subject" as a key in the environment. https://github.com/bluebirds-blue-jay/access-control/blob/13610cf9bfc8d8ac8553cc813e35b3454482458b/src/classes/condition-evaluator.ts#L81

[SylvainEstevez]

@broom9 I just checked our own project's implementation and indeed the subject is not passed by Bluejay. Instead we have an environmentFactory utility that extracts the most common environment values from the request, which I'm partially reproducing here:

import { Keys } from '@bluejay/access-control';

export function environmentFactory(req: Request): TAuthorizeEnvironment {
  return {
      bodyAttributes: Keys.list(req.body),
      body: req.body,
      headers: req.headers,
      queryAttributes: Keys.list(req.query),
      query: req.query,
      params: req.params,
      subject: req.subject.toJSON() // We store the subject on the request
    };
}

Then:

authorizer.authorize(resource, action, environmentFactory(req));

The {{{subject.id}}} in the previous example is indeed explicitly passed to the environment.

[broom9]

Thanks. This confirmed my understanding. So in a condition, both keys and values (if using the triple-brace macro) are from properties of the environment. It could use some clarification in the docs.

…

-- Wei Wei

On Jan 21, 2019, at 19:34, Sylvain ESTEVEZ ***@***.***> wrote: @broom9 I just checked our own project's implementation and indeed the subject is not passed by Bluejay. Instead we have an environmentFactory utility that extracts the most common environment values from the request, which I'm partially reproducing here: import { Keys } from ***@***.***/access-control'; export function environmentFactory(req: Request): TAuthorizeEnvironment { return { bodyAttributes: Keys.list(req.body), body: req.body, headers: req.headers, queryAttributes: Keys.list(req.query), query: req.query, params: req.params, subject: req.subject.toJSON() // We store the subject on the request }; } Then: authorizer.authorize(resource, action, environmentFactory(req)); The {{{subject.id}}} in the previous example is indeed explicitly passed to the environment. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[SylvainEstevez]

See example here: https://github.com/bluebirds-blue-jay/access-control#condition-variables.

I'm assuming that you found a way to achieve your goal @broom9, closing for housekeeping.