In the book "Agile web applications with Yii 1.1 and PHP5 the RBAC is implemented though authassignment and a bizrule. This should support the possibility of granting users with different roles in each project.
but whenever a user is assigned a role in a specific project a new record is added to the authassignment table with this role and that user. since there are 3 roles (owner, member, reader) this does not allow assigning the user to more than 3 projects and the user must be assigned different roles in these projects (otherwise integrity constraint will be violated).
Any ideas? Is this really a flaw in the RBAC implementation in the book?
thanks
This is probably more of a role for business rules than creating individual roles. For example, a user may be give a particular role that allows them to create and own a project and then a business rule would be used to ensure that only they can administer their project.
Related
I tried to understand RBAC in order to determine if it is a good solution for our problem.
Let say that the context is a bank. Among the several actors, we have account managers and clients.
I think I have understand RBAC for the account manager. If we imagine Account Managers can create, modify, view and remove accounts, then:
Account Manager is a role,
create, modify, view, remove are the operations,
accounts are objects
create account is one of the permissions associated to the role Account Manager
But my problem is about clients ... They can consult only their accounts.
My problem is: How can we specified this particular account in RBAC? Is it at least possible or must I choose another way of manage access control? And which of them?
As mentionned, Attribute based access control may be the good solution. And XACML could be used in an application with complex policies.
Here is a very understandable documentation about ABAC in Spring Security
Every user has one or more roles, every role has one or more permissions. So far I can gather all permissions that are associated to a user via the roles.
The Problem
Some permissions have some constraints. For example:
A user can edit all posts that belong to his site, but no other posts.
Therefore the permission "edit post" should have this constraint.
Regarding the model: If the Constraints are related to the permission, I can't resolve which constraints are active for the particular user.
The user model can have an attribute like "site", but not all users, that belong to one site should have the constraint mentioned above. Some of them should be able to edit all posts.
Question
What is the best way to determine which constraint is active for a particular user. Do I have to split this into seperate permissions and integrate the constraints into the permission model or is there a better solution? I stumbled upon attribute based access control but I am not sure if I should switch to a completely different appoach
Any help is appreciated :)
I replied the following to a previous similar question
You want to use a solution that is agnostic of the type of application it protects. That's the goal of XACML, the eXtensible Access Control Markup Language.
XACML provides attribute-based, policy-based access control (ABAC and PBAC). This gives you the ability to write extremely expressive authorization policies and managed them centrally in a single repository. A central authorization engine (called Policy Decision Point or PDP) will then serve decisions to your different applications.
The minimum set of attributes you will need is typically attributes about the user (Subject), the resource, and the action. XACML also lets you add environment attributes. This means you can write the following type of policy:
Doctors can view the medical records of patients they are assigned to.
Doctors describes the user / subject
view describes the action
medical records describes the targeted resource
of patients describes the targeted resource too. It's metadata about the resource
they are assigned to is an interesting case. It's an attribute that defines the relationship between the doctor and the patient. In ABAC, this gets implemented as doctor.id==patient.assignedDoctorId. This is one of the key benefits of using XACML.
Benefits of XACML include:
- the ability to externalize the authorization logic as mentioned by Bell
- the ability to update authorization logic without going through a development/deployment lifecycle
- the ability to have fine-grained authorization implemented the same way for many different applications
- the ability to have visibility and audits on the authorization logic
HTH
I’m looking for a methodology for generating new RBAC roles on demand. I am developing a RBAC system that will have two primary parameters. Rather than simply having a user associated with a role, and that role associated with a group of permissions; a user can be associated with a role “for a specific project,” and the user can then have the permissions of that role for that project only (or for other projects that the user holds that role for). A user can have a specific role on one project, and a different role on another project; the permissions granted to a role are consistent for every project; and a user’s permissions for a project are based on what role that user has on the project.
In response to RBAC system with two parameters, lmontrieux suggested using different roles for different projects. For example, if the role "admin" is used in projects "P1" and "P2", then create a role "P1:admin" and another role "P2:admin". This seems like the way to go, but I don’t want to create a static set of roles. First of all, there will be several projects and I shouldn’t write several sets of permissions that are identical in every way except for the project id. Second, and more importantly, projects “P3,” “P4” and “P5” don’t exist yet, and when they do exist they will be created by a user. Since I can’t create static role-based permissions for an unpredictable number of future projects, I need to develop a method for generating project-specific roles based upon a generic standard.
I assume this is a good application for the use of objects and classes, but I’m not sure how to structure it.
I am working on a multi-tenant cloud application and considering using E-mail addresses/passwords for general login credentials. However, I may have the same user (same E-mail address) associated with multiple tenants based on the planned sales model for this application. For example, multiple departments in the same company might be separate tenants, or separate companies must be separate tenants. In either case the same user (with same E-mail address) might be a user of these different tenants.
What are possible design strategies for handling such situation?
One approach I am considering is separating creation and update of the user E-mail credentials from the tenants. In this approach a tenant could invite a user (by sending an E-mail) and the user can use the same login credentials for access to all tenants, merely switching between tenants as desired.
What I have typically seen in current web applications is that the user has to have separate E-mail addresses for each tenants, which seems a burden for the user.
Thanks.
Assuming your question is about the technical design (and not the user experience), this is a pretty straight forward solution. Create the users independently from the tenants, and allow for a many to many relationship that represents the "has access to" phrase.
Depending on your chosen backend, there are different manifestations of the design pattern:
RDBMS: Create a user table, tenant table and a user_has_access_to relationship table
Directory Server (LDAP): Place the users into a single OU within the directory, and create the tenants as group objects. The users could then have the memberOf attribute set for each tenant they are able to access.
The LDAP option above has the limitation of overloading the group entity. If you are comfortable enough with LDAP schema definitions, you could just as easily create a tenant object and add a hasAccessToTenant attribute to your user object. Taking this approach would allow you to use groups to represent actual user groups (as the object type was intended to be used).
A more advanced design option would include the creation of a "has access to" relationship between tenants. Adding this, along with the user to tenant relationship, would open up more advanced relationship modeling. For example: a tenant with departments or divisions, allowing users with permission to the top level tenant to automatically "have access to" the divisions.
Using the same credential across namespaces in multi-tenant applications is technically possible. For example, when a user logs in, the application can check across the namespaces and determine which all namespaces he belongs to. There is a possibility, the user may have different levels of authorizations against these namespaces. This is also implementable.
The real problem is the experience the application can offer to such users. They will require a special landing page which will allow them to chose between the namespaces. The chosen namespace should be made quasi-permanent during the session, that is, until the user logs out. ( I am trying to implement this in a new application on GAE/Python27 )
Other possibilities are restricting the user to a single namespace and asking the user to use different credentials against each namespace, which seems to be the prevailing practice.
Does anyone have any tips as we develop an application that will require each user to be assigned a permission level. The permission level will determine what functionality is available to the user.
Any advice?
How would you (do you) employ such functionality in your application?
First you need to figure out what functionality you want to cover by your permission system, and in what detail:
Access to tables (List, CRUD)
Functions/Modules
Access on record level (=ACL)
Positive (grant) or Negative (revoke) semantics
What is the "admin" role allowed to do
If you want to restrict access to tables, you can easily set up an additional table containing all the table names, and grant select-list/select-record/insert/update/delete access to the roles/groups, as sketched by JV.
If you want to grant access to functions or modules, have a table of modules and grant execute to roles/groups.
Both functionality is equivalent to grants in SQL.
Access restriction on record level is much more complicated, as you need to model access rights on the status of a record (e.g. "public", "private", "released" in CMS apps), or have explicit permissions on each record.
If you want to implement a permission scheme equivalent to NTFS, you calculate the permission per record based on the group the user is assigned to, and have user-specific permissions that may override the group permissions, and revokes overriding grants.
My applications typically work on table+function / group level, which may be good enough, depending on your requirements.
This is the partial ER diagram for identity module in Turbogears, Python. It implements what you are looking forward to. Users are associated with groups and groups have associated permissions.
The two ways restricted feature availability can be implemented are:
(I prefer)In your controllers check the group to which the user belongs to and moderate your response to the View according to that. Thus View is just a renderer - no business logic.
The View gets the user details like groups and permissions and it decides what to display and what not to (MVC violated).
Read more about MVC (and Turbogears may be).
alt text http://jaivikram.verma.googlepages.com/temp.jpeg
It depends a lot of the language you use and the architecture of your application (web service ? client software ?).
For a server toy project, I though about assigning a minimum permission level to each command, and check it directly when a command network packet is received, triggering a permission error when the user hasn't a high enough level. I might not be suitable for another architecture.
It may be a bit of a dead end to pursue the concept of 'levels'. It may suit your current application, however a data model that consists of a mapping of roles to privileges is more general and suits most purposes.
Assign roles to users. A user may have more than one role, and their role(s) define the privileges they have. The concept is similar to groups, however 'role' is usually easily mapped directly to business logic (think of roles such as 'administrator', 'user', 'clerk', 'account manager', 'regional manager', etc). Privileges also map fairly directly to functions and data objects. You may also be able to map to implementations that use underlying platform access control (e.g. Java privileges).
In the controller code, you check (via their roles) that the user holds the required privilege to perform a function. It is also good practice to modify your views to hide functions that the user does not have the privileges to perform.
In your design you can visualise / document the access control system as a matrix (roles to privileges).