| activity | |
| initial post: | 25 feb 2010 |
| last update: | 05 mar 2010 |
This post is part of series of posts related to security:
In this way I found RBAC as been the most recommended.
A year has passed since then. And it took me two months to read about rbac, capability model, jaas, JackRabbit security and to implement this (of course being a personal project I worked only few hours at night, but still a long time).
So I will try to share this experience.
Even the use of "roles" in commercial applications is an old practice (beginning with 1970's) and a natural choice in these days, RBAC (or Role Based Access Control) is relatively recent theory. It is from the 1990s and was standardized in 2004.
Another approach (alternative to roles), the concept of groups can be used. As in operating systems. RBAC claim to be a better approach then user-groups. In fact the original intent of RBAC was to simplify the administration of access permissions by avoiding direct assignment of them to individual users. In groups, permissions can be assigned to users while in rbac only through roles can be assigned.
Previous to RBAC, other access control theories has been published. Firs by the U.S. Department of Defense and then formalized by the Bell-LaPadula model: Mandatory Access Control (MAC) and Discretionary Access Control (DAC).
In DAC, the owner of a resource can authorize other users to access/modify these resources (as in the operating systems). Instead, in the MAC model, the user cannot decide that, only the system can determine who is authorized to access a resource (more appropriate for military applications). Bell-LaPadula added the idea of "classifications" to users and resources ("no read up, no write down").
In DAC, the access to objects is based on the identity of users or the groups to which they belong. DAC was widely adopted and used in commercial and government applications. So DAC is guilty for the widely adoption of users-groups model.
RBAC is a non discretionary model. It is considered that the resources in an enterprise application are owned by the company, not by the individual employers that create or manipulate these documents (resources or objects as they are named in the security terminology). In fact RBAC was intentionally created for commercial applications and is particularly suited for commercial applications.
A role is similar to a group in the context of ACL. The difference is that the role is well defined by rbac in terms of what restriction you can apply on the roles, instead, a group can have other business meaning which can conduct to add additional restrictions on group / users relationship. These supplementary rules can conduct to impossibility to implement rbac relations. For example in rbac, the user-permission relation is many to many. This can be broken if constraints like this are present: 1) an user can be member of only one group at a time, or 2) only one group can be associated with a resource (as in unix file system).
And beside that, in rbac it is not allowed to assign permissions directly to the user. Only trough roles can be assigned. While in groups model, permissions can be assigned to users.
Anyway, the two can be used together, in jaas, the therm principal is used to denote the entity that poses roles which can be an user or a group.
In NIST RBAC (the standard), the following terms can be found:
RBAC claim that is increasing the level of security by facilitating a mechanism to enforce Least Privilege and Separation of Duty principles.
In short it means: different levels of permission at different times, depending on the task or function being performed.
The least privilege principle is achieved in a session trough role activation: the function that creates the session also establish a default set of active roles. But after that, the user can add or remove roles from the set of active roles. Details about this principle can be found on wiki: http://en.wikipedia.org/wiki/Principle_of_least_privilege
http://en.wikipedia.org/wiki/Separation_of_duties
is a way to prevent fraud or errors by not allowing an user to have a certain combination of roles. This restriction can be at login time or at the assignment time of users to roles.
Static separation of duties:
At user/roles administration time, the administrator cannot assign conflicting roles to users.
Dynamic separation of duties:
Means that the a user can own roles that may conflict and the limitation is during the session. It cannot activate in the same time 2 roles that conflicts.
In the paper "Specifying and enforcing constraints in role-based access control" [Jason Crampton] (http://www.isg.rhul.ac.uk/~jason/#Publications) i found another one: Historical separation of duty which add constrains like if you activated permission x, then you will not be allowed to activate permission y (here Crampton highlight that the life cycle of an object should be enforced by the businss rules (application itself), not by the security).
In this paper (Jason Crampton) are some suggestions how constraints can be implemented.
Miscellaneous:
RBAC is split into 4 main features that a system can implement:
RBAC 0 = flat/core rbac: it defines users, roles, permissions and the association between them.
RBAC 1 = hierarchical rbac: RBAC 0 + role hierarchy.
RBAC 2 = constrained rbac: RBAC 0 + constraints (static and dynamic separation of duties).
RBAC 1 & RBAC 2 can be implemented one without the other.
RBAC 3 = symmetric rbac: RBAC 1 + RBAC 2.
More about rbac can be found on NIST's site: http://csrc.nist.gov/groups/SNS/rbac, especially the FAQ: http://csrc.nist.gov/groups/SNS/rbac/faq.html
and in the book of the creators of the standard: http://www.amazon.com/Role-Based-Access-Control-David-Ferraiolo/dp/1580533701
RBAC is implemented on Solaris OS. [ToDo: search for products implementing rbac]
The Access Control Matrix is an abstract way to represent the association between subjects and the rights it have on objects in the system. The matrix was first introduced by Butler W. Lampson.
Many systems use Lampson's access control matrix to represent security policy.
In practice, in a system with a large number of users and objects, the matrix will become very large and will be sparsely populated. As such, an access control system is rarely implemented as a matrix but is almost always implemented as a representation of the matrix. There are two primary representations of the access control matrix as implemented in computer systems today: ACLs and capability lists.
capability lists (capability-based security)
This approach corresponds to storing the matrix by rows. A capability is an identifier that contains information to both identifies the object (protected resource) and specifies the access rights on the resource for the possessor of the capability.
Each subject is associated with a capability list, which stores its approved operations to all concerned objects.
Kerberos tickets are capabilities.
Advantages:
The principle advantage of capabilities is that it is easy to review all accesses that are authorized for a given subject.
Disadvantages:
It is difficult to review the subjects that can access a particular object. To do so would entail an examination of each and every capability list. It is also difficult to revoke access to an object given the need for a similar examination. For this reason, capability lists have been criticized in their support of DAC policies and therefore not commercially popular.
acl (access control list)
This approach corresponds to storing the matrix by columns. ACLs specify, for each protected resource, a list of individual users (or groups or roles), with their respective modes of access (e.g., read or write) to the resource.
Advantages:
It is easy to review the users that have access to an object as well as the operations that users can apply to the object.
It is easy to revoke access to an object by simply deleting an ACL entry.
These advantages make ACLs ideal for implementing DAC policies that are resource-oriented.
Disadvantages:
It is difficult to see what objects can access a particular subject. To do that you must examine each ACL on each resource on the system (scan every file and folder on a file system ?).
ACLs make it easy to add permissions to an object but hard to revoke all of a particular user’s permissions.
The use of ACLs has proved problematic in large heterogeneous systems: ACLs are tied to particular resources. A large number of users, each with many privileges, imply a very large number of user-privilege associations that are spread over potentially large numbers of independently managed platforms and applications. Thus, when a user takes on different responsibilities within the enterprise, administering these changes entails a thorough review, resulting in the selective addition or deletion of the user’s privileges, typically within numerous systems.
Symmetric RBAC (level 3) requires to include an interface for permission-role review for the administrators. These means that the administrator can see the complete set of objects that are associated with the permissions assigned to a particular user or role, or the complete set of operation and object pairs that are associated with the permissions that are assigned to a particular user or role.
And this can be easily achieved trough capability lists.
In Unix ACL is implemented as "protection bits" which is a limited version of ACLs and does not completely maps into the access control matrix.
RBAC can be implemented in both ways: using ACLs or capabilities. The Java 2 Security Model (JAAS) is capability-based.
Access Control Matrix on wiki: http://en.wikipedia.org/wiki/Access_Control_Matrix
Oracle Containers for J2EE: http://download.oracle.com/docs/cd/B32110_01/web.1013/b28957.pdf
Ward Cunningham Wiki: http://c2.com/cgi/wiki?CapabilitySecurityModel
RBAC started with this assumption:
- Roles are relatively stable within an organization while users and permissions may change rapidly. Users join/leave the organization or change roles within organization.
Although, many companies that used RBAC ends up having a "role explosion". This is due to the static nature of the roles and permission.
On this topic there is a popular example about a doctor that can access the records only for his patients. This will end up in creating roles like "Attending doctor to patient X", "... to patient Y". Or other examples of roles: "EMEA Sales Manager before 5PM" or in entertainment media "access movies but not under the age of 13 unless accompanied by an adult".
So, the roles should remain relatively stable. We should not create roles depending on different contexts. We cannot create a role for each combination of user and resource attributes. This attributes are normally already present on the entities used in the system. We cannot duplicate them in the RBAC mechanism. Beside that this attributes are permanently modified in the normal business flow of the application and cannot be permanently updated by the security administrator.
This "dynamic" attributes must be received by the policy evaluator from the application's entities at the time of the policy evaluation.
There is an extension to RBAC "Supporting Relationships in Access Control Using Role Based Access Control": http://csrc.nist.gov/groups/SNS/rbac/documents/design_implementation/rbac-rad-to-publish.ps
There are static attributes that are stored on the user credentials and dynamic attributes stored in the application, in the normal business entities and are retrieved at role evaluation time. The static attributes are maintained by the security administrator.
Also I found these materials:
Rule-Based RBAC [Al-Kahtani & Sandhu]
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.118.9833&rep=rep1&type=pdf
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.95.1071&rep=rep1&type=pdf
"Inclusion of subject-resource relationship [Barkley, Beznosov & Uppal 1999]"
Because of this limitation a new theory can be found on the internet: Attribute-Based Access Control (ABAC) and there are some debates on this topic on the net (RBAC vs. ABAC). http://www.axiomatics.com/is-rbac-really-deae.html
In my application I have such a situation: There are administrators and accountants on each account created in the application. Instead of creating roles like "administrator on account X" and "accountant on account Y", I have only 2 roles: administrator and accountant and the account information is stored on the user object. The permission assigned to an administrator can look like this (it is a JCR path):
"accounts/${user-home-folder-name}/* read, write". The variable ${} is replaced with the real folder name when the permission is first evaluated by retrieving this information from the current login object.
Many systems use negative permissions which add extra flexibility but also introduce complexity and confusion for the users.
In RBAC permissions are positive, in RBAC96 is this text:
"Some access control literature talks about "negative permissions" which deny, rather than confer, access. In our framework denial of access is modeled as a constraint rather than a negative permission." [Sandhu, R., Coyne, E., Feinstein, H., and Youman, C. Role-based access control models. IEEE (1996)]
"The NIST (nist rbac) model is based on positive permissions that confer the ability to do something on holders of the permission. The NIST model does not rule out the use of so-called negative permissions which deny access. Thus vendors are free to add this feature. Nevertheless vendors and users are cautioned that use of negative permissions can be very confusing, especially in presence of general hierarchies. The uses to which they are put can often be better achieved by judicious use of constraints." [The NIST Model for Role-Based Access Control: Towards A Unified Standard Ravi Sandhu, David Ferraiolcfi and Richard Kuhrô ]
Also in JAAS, permissions are positive. There are no negative permissions.
In DAC are two ways of managing authorization:
a. Closed policy: This policy allows access if there exists a corresponding positive authorization and denies it otherwise.
b. Open policy: This policy denies access if there exists a corresponding negative authorization and allows it otherwise.
In systems that use negative permissions, an important issue is how the conflicts can be resolved. A conflict appear when a user posses a permission that grants something and in the same time has a permission that explicitly denies the same thing (a negative permission). Conflict resolution policies have been discussed extensively in the literature. Two of them are:
a. Denial Takes Precedence (DTP): Negative authorizations are always adopted when conflict exists.
b. Permission Takes Precedence (PTP): Positive authorizations are always adopted when conflict exists.
This paper identify 4 more conflict resolutions which are more flexible then the mentioned above: "Rule-Based RBAC with Negative Authorization" [Mohammad A. Al-Kahtani, Ravi Sandhu].
Another work on conflict resolutions is: Conflicts in Policy-based Distributed Systems Management [E. Lupu, M. Sloman] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.32.8645&rep=rep1&type=pdf
- part 1: a security model
- part 2: jaas- working on it
- part 3: jaas in jackrabbit using capability model
In this way I found RBAC as been the most recommended.
A year has passed since then. And it took me two months to read about rbac, capability model, jaas, JackRabbit security and to implement this (of course being a personal project I worked only few hours at night, but still a long time).
So I will try to share this experience.
rbac - introduction
Even the use of "roles" in commercial applications is an old practice (beginning with 1970's) and a natural choice in these days, RBAC (or Role Based Access Control) is relatively recent theory. It is from the 1990s and was standardized in 2004.
Another approach (alternative to roles), the concept of groups can be used. As in operating systems. RBAC claim to be a better approach then user-groups. In fact the original intent of RBAC was to simplify the administration of access permissions by avoiding direct assignment of them to individual users. In groups, permissions can be assigned to users while in rbac only through roles can be assigned.
Previous to RBAC, other access control theories has been published. Firs by the U.S. Department of Defense and then formalized by the Bell-LaPadula model: Mandatory Access Control (MAC) and Discretionary Access Control (DAC).
In DAC, the owner of a resource can authorize other users to access/modify these resources (as in the operating systems). Instead, in the MAC model, the user cannot decide that, only the system can determine who is authorized to access a resource (more appropriate for military applications). Bell-LaPadula added the idea of "classifications" to users and resources ("no read up, no write down").
In DAC, the access to objects is based on the identity of users or the groups to which they belong. DAC was widely adopted and used in commercial and government applications. So DAC is guilty for the widely adoption of users-groups model.
RBAC is a non discretionary model. It is considered that the resources in an enterprise application are owned by the company, not by the individual employers that create or manipulate these documents (resources or objects as they are named in the security terminology). In fact RBAC was intentionally created for commercial applications and is particularly suited for commercial applications.
roles and groups
A role is similar to a group in the context of ACL. The difference is that the role is well defined by rbac in terms of what restriction you can apply on the roles, instead, a group can have other business meaning which can conduct to add additional restrictions on group / users relationship. These supplementary rules can conduct to impossibility to implement rbac relations. For example in rbac, the user-permission relation is many to many. This can be broken if constraints like this are present: 1) an user can be member of only one group at a time, or 2) only one group can be associated with a resource (as in unix file system).
And beside that, in rbac it is not allowed to assign permissions directly to the user. Only trough roles can be assigned. While in groups model, permissions can be assigned to users.
Anyway, the two can be used together, in jaas, the therm principal is used to denote the entity that poses roles which can be an user or a group.
rbac model
In NIST RBAC (the standard), the following terms can be found:
- users - refers to people who interface with the system.
- roles - a role is a collection of permissions. Users receive permissions only through roles.
- permissions - a permission is composed of operations (or actions) together with the object (or protected resource) on which can be performed.
- subject -computer process acting on behalf of a user. Within a session, an user can activate only a subset of his roles. This mean a subject has the user roles or a subset of these roles. This features leads to the principle of least privilege and is called role activation.
- session - the login period. The subject is defined within a session. Also the activation of the roles it is done during a session.
RBAC claim that is increasing the level of security by facilitating a mechanism to enforce Least Privilege and Separation of Duty principles.
the principle of least privilege
In short it means: different levels of permission at different times, depending on the task or function being performed.
The least privilege principle is achieved in a session trough role activation: the function that creates the session also establish a default set of active roles. But after that, the user can add or remove roles from the set of active roles. Details about this principle can be found on wiki: http://en.wikipedia.org/wiki/Principle_of_least_privilege
separation of duties
http://en.wikipedia.org/wiki/Separation_of_duties
is a way to prevent fraud or errors by not allowing an user to have a certain combination of roles. This restriction can be at login time or at the assignment time of users to roles.
Static separation of duties:
At user/roles administration time, the administrator cannot assign conflicting roles to users.
Dynamic separation of duties:
Means that the a user can own roles that may conflict and the limitation is during the session. It cannot activate in the same time 2 roles that conflicts.
In the paper "Specifying and enforcing constraints in role-based access control" [Jason Crampton] (http://www.isg.rhul.ac.uk/~jason/#Publications) i found another one: Historical separation of duty which add constrains like if you activated permission x, then you will not be allowed to activate permission y (here Crampton highlight that the life cycle of an object should be enforced by the businss rules (application itself), not by the security).
In this paper (Jason Crampton) are some suggestions how constraints can be implemented.
Miscellaneous:
RBAC is split into 4 main features that a system can implement:
RBAC 0 = flat/core rbac: it defines users, roles, permissions and the association between them.
RBAC 1 = hierarchical rbac: RBAC 0 + role hierarchy.
RBAC 2 = constrained rbac: RBAC 0 + constraints (static and dynamic separation of duties).
RBAC 1 & RBAC 2 can be implemented one without the other.
RBAC 3 = symmetric rbac: RBAC 1 + RBAC 2.
More about rbac can be found on NIST's site: http://csrc.nist.gov/groups/SNS/rbac, especially the FAQ: http://csrc.nist.gov/groups/SNS/rbac/faq.html
and in the book of the creators of the standard: http://www.amazon.com/Role-Based-Access-Control-David-Ferraiolo/dp/1580533701
RBAC is implemented on Solaris OS. [ToDo: search for products implementing rbac]
access control matrix (acl vs. capability model)
The Access Control Matrix is an abstract way to represent the association between subjects and the rights it have on objects in the system. The matrix was first introduced by Butler W. Lampson.
Many systems use Lampson's access control matrix to represent security policy.
Fig.1 - The Lampson's access control matrix.
In practice, in a system with a large number of users and objects, the matrix will become very large and will be sparsely populated. As such, an access control system is rarely implemented as a matrix but is almost always implemented as a representation of the matrix. There are two primary representations of the access control matrix as implemented in computer systems today: ACLs and capability lists.
capability lists (capability-based security)
This approach corresponds to storing the matrix by rows. A capability is an identifier that contains information to both identifies the object (protected resource) and specifies the access rights on the resource for the possessor of the capability.
Each subject is associated with a capability list, which stores its approved operations to all concerned objects.
Kerberos tickets are capabilities.
Advantages:
The principle advantage of capabilities is that it is easy to review all accesses that are authorized for a given subject.
Disadvantages:
It is difficult to review the subjects that can access a particular object. To do so would entail an examination of each and every capability list. It is also difficult to revoke access to an object given the need for a similar examination. For this reason, capability lists have been criticized in their support of DAC policies and therefore not commercially popular.
acl (access control list)
This approach corresponds to storing the matrix by columns. ACLs specify, for each protected resource, a list of individual users (or groups or roles), with their respective modes of access (e.g., read or write) to the resource.
Advantages:
It is easy to review the users that have access to an object as well as the operations that users can apply to the object.
It is easy to revoke access to an object by simply deleting an ACL entry.
These advantages make ACLs ideal for implementing DAC policies that are resource-oriented.
Disadvantages:
It is difficult to see what objects can access a particular subject. To do that you must examine each ACL on each resource on the system (scan every file and folder on a file system ?).
ACLs make it easy to add permissions to an object but hard to revoke all of a particular user’s permissions.
The use of ACLs has proved problematic in large heterogeneous systems: ACLs are tied to particular resources. A large number of users, each with many privileges, imply a very large number of user-privilege associations that are spread over potentially large numbers of independently managed platforms and applications. Thus, when a user takes on different responsibilities within the enterprise, administering these changes entails a thorough review, resulting in the selective addition or deletion of the user’s privileges, typically within numerous systems.
Symmetric RBAC (level 3) requires to include an interface for permission-role review for the administrators. These means that the administrator can see the complete set of objects that are associated with the permissions assigned to a particular user or role, or the complete set of operation and object pairs that are associated with the permissions that are assigned to a particular user or role.
And this can be easily achieved trough capability lists.
In Unix ACL is implemented as "protection bits" which is a limited version of ACLs and does not completely maps into the access control matrix.
RBAC can be implemented in both ways: using ACLs or capabilities. The Java 2 Security Model (JAAS) is capability-based.
Access Control Matrix on wiki: http://en.wikipedia.org/wiki/Access_Control_Matrix
Oracle Containers for J2EE: http://download.oracle.com/docs/cd/B32110_01/web.1013/b28957.pdf
Ward Cunningham Wiki: http://c2.com/cgi/wiki?CapabilitySecurityModel
the drawbacks and criticism of rbac
RBAC started with this assumption:
- Roles are relatively stable within an organization while users and permissions may change rapidly. Users join/leave the organization or change roles within organization.
Although, many companies that used RBAC ends up having a "role explosion". This is due to the static nature of the roles and permission.
On this topic there is a popular example about a doctor that can access the records only for his patients. This will end up in creating roles like "Attending doctor to patient X", "... to patient Y". Or other examples of roles: "EMEA Sales Manager before 5PM" or in entertainment media "access movies but not under the age of 13 unless accompanied by an adult".
So, the roles should remain relatively stable. We should not create roles depending on different contexts. We cannot create a role for each combination of user and resource attributes. This attributes are normally already present on the entities used in the system. We cannot duplicate them in the RBAC mechanism. Beside that this attributes are permanently modified in the normal business flow of the application and cannot be permanently updated by the security administrator.
This "dynamic" attributes must be received by the policy evaluator from the application's entities at the time of the policy evaluation.
There is an extension to RBAC "Supporting Relationships in Access Control Using Role Based Access Control": http://csrc.nist.gov/groups/SNS/rbac/documents/design_implementation/rbac-rad-to-publish.ps
There are static attributes that are stored on the user credentials and dynamic attributes stored in the application, in the normal business entities and are retrieved at role evaluation time. The static attributes are maintained by the security administrator.
Also I found these materials:
Rule-Based RBAC [Al-Kahtani & Sandhu]
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.118.9833&rep=rep1&type=pdf
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.95.1071&rep=rep1&type=pdf
"Inclusion of subject-resource relationship [Barkley, Beznosov & Uppal 1999]"
Because of this limitation a new theory can be found on the internet: Attribute-Based Access Control (ABAC) and there are some debates on this topic on the net (RBAC vs. ABAC). http://www.axiomatics.com/is-rbac-really-deae.html
In my application I have such a situation: There are administrators and accountants on each account created in the application. Instead of creating roles like "administrator on account X" and "accountant on account Y", I have only 2 roles: administrator and accountant and the account information is stored on the user object. The permission assigned to an administrator can look like this (it is a JCR path):
"accounts/${user-home-folder-name}/* read, write". The variable ${} is replaced with the real folder name when the permission is first evaluated by retrieving this information from the current login object.
no negative permissions
Many systems use negative permissions which add extra flexibility but also introduce complexity and confusion for the users.
In RBAC permissions are positive, in RBAC96 is this text:
"Some access control literature talks about "negative permissions" which deny, rather than confer, access. In our framework denial of access is modeled as a constraint rather than a negative permission." [Sandhu, R., Coyne, E., Feinstein, H., and Youman, C. Role-based access control models. IEEE (1996)]
"The NIST (nist rbac) model is based on positive permissions that confer the ability to do something on holders of the permission. The NIST model does not rule out the use of so-called negative permissions which deny access. Thus vendors are free to add this feature. Nevertheless vendors and users are cautioned that use of negative permissions can be very confusing, especially in presence of general hierarchies. The uses to which they are put can often be better achieved by judicious use of constraints." [The NIST Model for Role-Based Access Control: Towards A Unified Standard Ravi Sandhu, David Ferraiolcfi and Richard Kuhrô ]
Also in JAAS, permissions are positive. There are no negative permissions.
In DAC are two ways of managing authorization:
a. Closed policy: This policy allows access if there exists a corresponding positive authorization and denies it otherwise.
b. Open policy: This policy denies access if there exists a corresponding negative authorization and allows it otherwise.
In systems that use negative permissions, an important issue is how the conflicts can be resolved. A conflict appear when a user posses a permission that grants something and in the same time has a permission that explicitly denies the same thing (a negative permission). Conflict resolution policies have been discussed extensively in the literature. Two of them are:
a. Denial Takes Precedence (DTP): Negative authorizations are always adopted when conflict exists.
b. Permission Takes Precedence (PTP): Positive authorizations are always adopted when conflict exists.
This paper identify 4 more conflict resolutions which are more flexible then the mentioned above: "Rule-Based RBAC with Negative Authorization" [Mohammad A. Al-Kahtani, Ravi Sandhu].
Another work on conflict resolutions is: Conflicts in Policy-based Distributed Systems Management [E. Lupu, M. Sloman] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.32.8645&rep=rep1&type=pdf
No comments:
Post a Comment