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.
Related
Here is the scenario, I have a service containing many records. My service also has many users, each with the ability to create, read, update and delete records. The ability to perform these operations on each record must be controlled at the record level.
For example, user A can only read and update record 1 but user B can read, update and delete records 1, 2 and 3 and user C can perform all operations on all records.
How if at all, can this be done using Azure AD?
Obviously, using application roles is not sufficient because that gives the user uniform access rights to all records.
The tenant is also not useful because its the same for all users (in this example).
I definitely do not want to define access rights for every record individually, I would like to do something like assigning roles to a user group and then somehow assign records to the group.
Is there a standard way to deal with this type of resource based authorization?
As you correctly mention, role based access or authorization is very generic and using that, a user with specific role gets access (or gets denied access) to all resources. (If your sceanrio permits, you could make it a little better by dividing your resources into a few types and give access for 1 or more types of resources to 1 or more roles).
When trying to control access for each record individually, you will need to implement custom logic for resource based authorization. Typically applications utilize a mix of role-based and resource-based authorization driven by their requirements.
In the end it will boil down to a mapping that you need to maintain between 3 things
Resource (or a collection of resources)
Azure AD object (like role, group, individual user that is being given permission)
Permission that you're giving (understood and enforced by your application e.g. Blogs.Create permission for a Blogs application)
Relevant Documentation available on Microsoft Docs
Role-based and resource-based authorization
This documentation talks about similar concepts and shows a good example which makes use of both role based and resource based. CRUD operations on resources based on roles and then special privileges on specific resource for the owner of that resource (i.e. resource based)
Code Samples
Multi-tenant Survey Application Code
Code base for the documentation link above
Authorization in a web app using Azure AD groups & group claims
This one provides a sample task tracker application where users can share tasks with other users or Azure AD groups. Again you will see a mapping between resources (i.e. tasks in this case) and Azure AD objects (i.e. Users or Groups) is being maintained in sample database.
Assigning Application Roles for groups
Since you mentioned this as part of your question, just letting you know that this is possible from Azure Portal but only if you have Azure AD Premium license (I'm not sure which specific ones support it, but search on Group based assignments feature and you'll find it.)
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.
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.
I work on a vb.net winforms app where we currently are using simple roles for security. We enable/disable specific controls based on if the current user has the required role. We are to the point where this is no longer granular enough.
Our application is based on different physical locations we call sites. A user might have permission to do something (for example, edit a site's configuration) at one site but not another. Therefore, we now need to lookup permissions based on current user AND current site. Also, a certain user's permissions may be very specific to themselves ie. no other user's permissions are exactly the same as another user's. Therefore we need a security model that's more permissions based rather than role based.
What's the best way to design a new permissions model that can meet these requirements? I want to make sure that it's easy to implement the checking in the code (I don't want a million if statements sprinkled in our SetUIPermissions methods) and we don't want to have to update every user (400+ and counting) each time we add a new permission. Because of this last requirement I think we need to keep the idea of roles but possibly add/remove exceptions for particular permissions for specific users.
Any ideas?
You're on the right track with the roles and permissions. It's a relatively common solution to have a role refer to a set of "default" permissions; by having a user have a role and a set of permissions, you allow for the role to be overridden by the set of permissions specifically granted / revoked for that user. This gives reasonable flexibility and granularity, and supports your situation of adding new permissions (in the role) without needing to touch every user.
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).