search

OWASP / rbac

PHP-RBAC is an authorization library for PHP. It provides developers with NIST Level 2 Standard Role Based Access Control and more, in the fastest implementation yet.
http://phprbac.net/
Apache License 2.0
429 stars 141 forks source link

Granularity of Roles/Permissions #50

Open spinetrak opened 10 years ago

spinetrak commented 10 years ago

I am looking to implement an RBAC-based authorization/entitlements management system at work (1000 employees) for various in-house applications, and thus found your PHP:RBAC library.

If you don't mind, I have a conceptual question about "permissions". Basically, permissions is the entitlement to perform action x on resource y, simple enough.

In PHP:RBAC, these distinct things (actions, resources) are merged into the single entity "permission". So the question then is, how to deal with a relatively simple use case:

  1. A user may have a role called "Translator"
  2. "Translators" may translate (action) files (resource)
  3. However, a given translator may only translate certain files, not all, depending on say a) language b) subject matter c) criticality

This is a little contrived of an example (not much terrible can happen if a Chinese translator had the permission to translate a Russian file where he has no clue about the subject matter - he is simply not going to do it), but I could think of more sensitive scenarios (say "Sales Person" may read (action) revenue data (resource) - but for example, he may clearly not be permissioned to read all Revenue data for all markets an all products above a given revenue threshold ).

So, how would you suggest people model this level of granularity, or does this effectively exceed the scope of what's possible with PHP:RBAC?

I worry that we'd end up with an unmanagable inflation of Roles and/or Resources, e.g. we would have to have one "Translator" role for each language (or one "Sales Person" role for each market), which right there could be quite a few roles and/or one permission for each subject matter and criticality combination (or for each product and revenue threshold combination), and we haven't even covered all actions (only read, but not say update).

Of course, we'd like to keep it as simple as possible - any suggestions?

Thanks!

abiusx commented 10 years ago

This is an excellent question. I think it would be a good idea to post it as an issue on GitHub, so that other people can benefit from it as I beleive a lot of users have this question.

Now let me get to the answer and explain this. PHP-RBAC is a functionality access control library, meaning that it can provide you with access control for your application’s functionality, and is not suited to provide access control for data. In fact, no RBAC library is. Data access control is part of the application logic, and has to stay besides data.

Let me exaplain more,

For every data record in your application, you have to define the access control (or access control group) for that data. It should get modified with the data, get deleted with the data and get duplicated with the data. Thus it is strongly coupled with the data record and should not be placed in an external library.

You can use PHP-RBAC infrastructure to make decisions regarding role trees for your data permissions, but it is not wise to modify the RBAC tree frequently (at least as frequent as you add/remove data records).

In fact, PHP-RBAC is particularly optimized for lookup, and is pretty darn slow when modifying the tree. The modificatin time scales with the number of roles/permissions whereas lookup time remains constant (or at least scales with log(log(N)) ).

Please let me know if you had any further questions,

On Sep 22, 2014, at 3:17 AM, spinetrak notifications@github.com wrote:

I am looking to implement an RBAC-based authorization/entitlements management system at work (1000 employees) for various in-house applications, and thus found your PHP:RBAC library.

If you don't mind, I have a conceptual question about "permissions". Basically, permissions is the entitlement to perform action x on resource y, simple enough.

In PHP:RBAC, these distinct things (actions, resources) are merged into the single entity "permission". So the question then is, how to deal with a relatively simple use case:

A user may have a role called "Translator" "Translators" may translate (action) files (resource) However, a given translator may only translate certain files, not all, depending on say a) language b) subject matter c) criticality This is a little contrived of an example (not much terrible can happen if a Chinese translator had the permission to translate a Russian file where he has no clue about the subject matter - he is simply not going to do it), but I could think of more sensitive scenarios (say "Sales Person" may read (action) revenue data (resource) - but for example, he may clearly not be permissioned to read all Revenue data for all markets an all products above a given revenue threshold ).

So, how would you suggest people model this level of granularity, or does this effectively exceed the scope of what's possible with PHP:RBAC?

I worry that we'd end up with an unmanagable inflation of Roles and/or Resources, e.g. we would have to have one "Translator" role for each language (or one "Sales Person" role for each market), which right there could be quite a few roles and/or one permission for each subject matter and criticality combination (or for each product and revenue threshold combination), and we haven't even covered all actions (only read, but not say update).

Of course, we'd like to keep it as simple as possible - any suggestions?

Thanks!

— Reply to this email directly or view it on GitHub https://github.com/OWASP/rbac/issues/50.

spinetrak commented 10 years ago

Thanks a lot for your response!

I understand that roles/permissions must not be modified frequently, that's fine, but I feel the distinction between functionality access control and data access control is a little blurry, or maybe it's even a red herring, at least in the scenario that I have in mind. To state it briefly: In many many situations, the application's functionality is to provide (or restrict) access to data.

Simple example: Let's say I have a Translators' Application to manage translations, and let's say my application logic knows how to categorize translation files into language, sensitivity, subject matter - i.e. each file will have one language, one sensitivity, one subject matter - which I think means I can satisfy the condition "[f]or every data record in your application, you have to define the access control (or access control group) for that data".

Now I want to assign (give access to) these files to users. To do this correctly, the user must a) be a translator (definitely sounds like a role to me) b) have the language as one of the languages that he can translate (sounds like a user attribute, but could be either a role or a permission as well) c) be permissioned to at least the level of sensitivity represented by the file (sounds like a permission to me, but could be a role as well) d) must be knowledgeable in the subject matter (again, sounds like a user attribute, but could be either a role or a permission as well)

Note that these facts about a given translator rarely change.

So the way I look at it is I have the following options

  1. Create roles like Translator_EN, Translator_FR, Translator_DE, etc (i.e. one role per language, and a given translator may have multiple Translator_XX role) - intuitive and simple enough
  2. Each of these roles gets the permission - say "logon to translator application","translate" (as opposed to "review") - and I can now at least restrict each translator to only specific languages.
  3. But now I still have a problem with the other two criteria (sensitivity and subject matter) - these feel most naturally like permissions, but I'd have to assign them to specific translators, not to any translator role, thus breaking a fundamental RBAC principle, if I am not mistaken.

Alternatively, I suppose I could have one Translator role per sensitivity level (more fitting into the model of hierarchical Roles) and make language and subject matter user attributes to be handled/managed entirely outside of the RBAC tree (for example, as LDAP attributes in the translators' user accounts).

Sorry for the longish train of thought, but it appears to me that there could be quite a long list of facts/attributes (about users, etc.) other than roles that in reality determine whether a given permission should be granted or not, so I am looking for the most elegant (least complex) approach to modeling that.

MysterAitch commented 10 years ago

You could have a separate streams/trees for sensitivity roles and subject matter expertise roles. For example, you have a user with the ("Translator_XX" && "Translator_YY" && "Access_Confidential" && "Expert_WorldAffairs") roles.

Your pages/documents could then require the following permissions, each granted by the different roles above:

Note that in this respect, a user has multiple roles - the user can have access to confidential material and is still an expert in 'world affairs' even without being a translator - while you retain granularity with respect to the permissions required with accessing your documents.

Also note that this approach will require some discipline with regards to ensuring your expertise roles never grant access-related permissions (and vice-versa).

One of the gotcha's with this approach is that it would be for your application to define what happens if there is an undefined permission for a given resource. For example, does having no defined 'access_' permission imply that there is no restriction on that resource, or that nobody has permission?

spinetrak commented 10 years ago

Yes, ok, fair enough - so, basically all user attributes would be modelled as roles, in their own separate role trees, where applicable. The gotchas you mention are reasonable trade-offs. I still worry that I may end up with an excessive number of roles, but maybe there is no way around that, and keeping these attributes external (i.e. as user attributes say in an LDAP directory, as I had considered) would have other disadvantages.

Thanks!

abiusx commented 10 years ago

If you have a limited number of attributes, you can model them either as roles or permissions. Just keep in mind that you should not set roles to be checked later. Roles are intermediatary just for checking permissions, you should now have a use case in mind as “see if user x has role r”. -A

On Sep 22, 2014, at 7:13 AM, spinetrak notifications@github.com wrote:

Yes, ok, fair enough - so, basically all user attributes would be modelled as roles, in their own separate role trees, where applicable. The gotchas you mention are reasonable trade-offs. I still worry that I may end up with an excessive number of roles, but maybe there is no way around that, and keeping these attributes external (i.e. as user attributes say in an LDAP directory, as I had considered) would have other disadvantages.

Thanks!

— Reply to this email directly or view it on GitHub https://github.com/OWASP/rbac/issues/50#issuecomment-56358877.