If you allow organization wide access to your application, how do you default users to a specific role in your app?
i'm following an example from a tutorial, and it works great if I specify individual users to have specific roles, but I need to be able to leave this open to the broader org but I only want them using the "user" level.
I would suggest using Google Groups for roles that may involve many individuals where it would become cumbersome to update members in the App Maker deployment settings. There is some information here https://developers.google.com/appmaker/security/secure-your-app#add_members_to_roles.
If this is strictly an access restriction to the application itself to a subset of individuals within a domain then groups can still be used to restrict access to the application within the application settings.
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.)
I have a question regarding Cumulocity. I want to create a site hierarchy in Cumulocity, we can go up to sub-tenant level only but I want to create a hierarchy up to 2 level.
Let's take an example of schools, its locations, and different branches. Here I want to attach an owner with each branch and that owner should be able to register only their own users and devices. I was trying to achieve it using groups, roles etc but was not able to do it. If anyone can suggest how to proceed for this use case.
I can see two possible options using which this can be tried:
Groups
Custom Apps (Angular apps)
But I am not sure how to proceed as there is no direct UI for the user to group assignment and REST API for this assignment is giving me errors.
You can use the inventory permissions for configuring access rights that are limited to a certain group see documentation
The managing of only your own users can be achieved by giving a user the global permission for USER_MANAGEMENT_CREATE. Make sure to revoke the ADMIN and READ role as well.
I would not recommend to solve this with apps on the UI side. That way you can of course hide information from the user but he may still be access it via API. Only with the RBAC you can really ensure on API level that the access is managed correctly.
Currently I'm building a web app. So far I only have regular users. However, due to some requirements I need to have special admin accounts for the app administrators. I'm wondering now how these are usually implemented. The requirement is, that they use the same login mask as regular users and behave the same except for the additional capabilities. To differentiate I could put an admin flag into the users' profile or put the admins into a separate table in my DB. Maybe the the second option scales better for potential additional user groups. Also, how could these admins be signed up? I don't want to use predefined usernames I check against in the login handler. I know the question is rather general. I'm just looking for some directions.
Since you didn't give information about the platform(s) you are using, I can only give theoretical answer. While a simple "isadmin checkbox" will do the job for only separating normal users and admins, but if you will need another user type such as "power users" etc. you will keep adding new columns to your table, which is not ideal. Basically you can use a "Role Based" or a "Permission" based approach. In Role based, as the name implies, you assign each user a role and give access to specific resources depending on the role. In the "Permissions" approach you define for each user the permissions they have (resources to access, actions they can perform). Also you could combine these two approaches, where you assign each user his role and define permissions for each role.
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.