I am creating an application that uses Azure AD user groups to grant permissions to specific resources. For example, a particular set of documents can only be accessed by users in specific groups. The application receives the group ids as claims on the JWT and ensures that only documents assigned to groups in the claims are visible.
Now, the question is how to manage groups correctly in Azure AD. When users are assigned to a group become a member of that group and any groups that group is nested in. This seems to imply that my group nesting should be the reverse of the tree structure I would like. Something like this:
Admin --> member of --> Group with most access --> member of --> group with less access --> member of --> group with least access.
To me this seems backwards but it provides the correct access rights to users added to each group.
Am I way off base here or is this a reasonable way to manage access rights with AD groups?
#JoyWang already covered some good points in answer above. Here are some additional considerations. Disclaimer: Due to nature of question, my answer here is mostly opinion and learning from some cases. Idea is to share how I have seen groups getting used along with some related info.
Are the groups specific to your application or more general purpose? Group membership and nested groups are usually used to organize users & groups logically/intuitively rather than design permissions for specific application
Many times Azure AD Groups are used by more than one application and may have a lifetime longer than any one specific application you're developing.
The way you are thinking about nesting groups based on which one has more access v/s less access you're probably concerned about only one particular application that you're developing and thinking about a group's access to this application. This approach will work out if the groups you plan to create are also very application specific and will NOT be used for any other purpose.
Example1: Your application is a blogging app and groups you create in Azure AD are Viewer, Contributor and Admin. (Admin > Contributor > Viewer)
Example2: You have an enterprise using Azure AD and groups organize users logically, say deparatment wise Marketing, Human Resources, Engineering etc.
So, the way you describe nested groups based on lower access permissions to higher, it will technically work out for a simpler scenario like in Example1 but not for Example2 where groups are more general purpose.
Many times general purpose groups already exist and you're expected to reuse them rather than create new ones for your application which require new assignments/membership all over again, but this may or may not be applicable in your specific case.
Also, there can be multiple people managing these groups and their membership so any design/organization pattern you come up with should give importance to intuitiveness even if you have to sacrifice minor application specific efficiency sometimes.
In my opinion, you can look at both flat or nested groups.. if it makes sense from an organization of users and groups standpoint, not just access permissions. Another fictious example: Marketing Group can have a member group like Marketing Content Approvers because it's a subset of Marketing people.
Do consider Application Roles.
They are specific to an application, tied to it's manifest and can be available to you as part of claims in token.
There can be situations like individual resource based access where you want to give permissions to a specific resource where Application Roles may or may not make sense and you still need to rely on groups or users directly. In any case, it's another helpful option available to you.
Managing Groups (as you've asked about this in comments)
Take a look at Self Service Group Management Scenarios (Delegated v/s Self-service) and also Dynamic Groups for dynamic membership rules based on attributes (requires Premium license though).
In AAD, the permissions of a member in the groups depend on the biggest permission of the group which he is a member of. For example, group A can access a resource and group B can't access it, the man is both in group A and B, then he will be able to access the resource.
To me this seems backwards but it provides the correct access rights to users added to each group.
Let we call the three groups as A,B,C, the permission of them is A > B >C. Obviously, if you add A to B, the permissions of A and B both have not been affected. But if you add B to A, the members in A or B will both have the biggest permission, it is no what you want. The same with B and C. This is why it provides the correct access rights to users added to each group as you said.
So in my personal opinion, seems no need to use nested groups, just use three groups with different permissions, it's enough.
Related
My team and I are handling hundreds of subscriptions that are belonging to different teams.
Many of them have different needs in terms of security, services to be used, etc whereas we, as a central platform, also make sure that everyone work with the same baseline (security, monitoring, automation, etc.).
We of course have a need to handle RBAC and we are using custom roles a lot. I was wondering if there was a way to create a custom role based on another one to benefit from "classic inheritance".
So I could create for example a role named "basic_user" that would contains a set of "Actions" and an "advanced_user" could have "basic_user" accesses plus additional ones, and so on with "super_advanced_user".
I know that Microsoft has designed it the opposite way so far, allowing us to assign multiple roles to a given individual/group, but for internal design reasons, we would like to stick to one role assignment for a given recipient (one AAD group containing all people accordingly to their role).
Is this something technically feasible/reproducible or does anyone heard about such a feature ? Or maybe is it something we should not consider because of some reasons you'd want to highlight ?
The feature that you would like to implement as you described is not currently not available as you were already aware of this. But however you can post about this feature directly via this link. It will reviewed directly by the Microsoft engineering teams and will respond.
I have an enterprise application in Azure with some roles defined, let's say:
professor role
student role
staff role
Then I have some Active Directory groups which are nested, like:
root professor group PROF
nested professor group PROF1
nested professor group PROF2
and many more similar, even more nested...
root student group STUD
nested student group STUD1
nested student group STUD2
and many more similar, even more nested...
root staff group STAFF
nested student group STAFF1
nested student group STAFF2
and many more similar, even more nested...
I can assign users and AD groups to those roles. However, when I want to assign a group to a role, it works only when a user is a direct member of the group. If, for instance, I add the whole group STUD to a role, it does not work with role assignment. Therefore I have to add all the single nested roles to the role, which is quite time consuming.
But that would have been acceptable as one-time-solution. Bad thing is, there are new groups and users constantly. And I'd have to keep the role assignments up-to-date manually all the time.
Ideally I'd like to say: everyone from the STUD root AD group gets the student role etc. Apparently this is not possible:
https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/15718164-add-support-for-nested-groups-in-azure-ad-app-acc
Is it maybe possible to do it via some automated script? Maybe you have some other ideas?
Thanks in advance!
as you've discovered, azure ad currently does not treat nested groups nicely for a variety of situations, and as you have found in that thread that you posted microsoft is starting to work on a workaround.
so the question is how much effort do you want to spend on trying to implement something that will likely be some kind of built in functionality in the medium term when microsoft releases a solution?
there are things you can do, like write a powershell script to flatten a group for example. but you would call that manually. to keep it clean, i would create a parent group for each appplication registration role. eg, create like a group called app_x_prof or something, put prof group in there. then flatten that. but that's still pretty manual.
if you really wanted to automate that, there are ways. eg, you could combine creating app role specific groups, add nested groups to that, then, run a power automate (flow) that you make periodically that goes through those specially named groups to grab all the users from nested groups and copy them to the root group..
all depends on how much effort and time.
I would like to find out all of the user which are associated in some roles. I have seen the UserLocalService that provides the method to find the users in a particular role. But I want a method to which I can pass an array of roleIds and it shall return me the list of users in those roles.
One way is to write custom SQL, but I would like to get it done by using the API only.
Is that possible with Liferay API??
Call the API multiple times? Create a new service that does this for you so that you only have a single call to (your) API?
I know, this is probably not the answer that you expected. Note that roles in Liferay can be scoped globally (to the whole portal, called 'regular') or to an individual site or organization. Thus just giving a roleId would limit you to the global roles (as the others would require the site's or organization's groupId).
Stepping back and looking at what you want to achieve, my first guess is that you have some semantics in being associated with a specific role - kind of like... a usergroup? A role is designed to give permissions to users, while a usergroup is designed to group users. UserLocalService also has getUserGroupUsers - this also only takes a single usergroup id, but at least it's a single (global) scope by definition and not ambiguous like roles.
I'm using AzMan (1.0) for an ASP.Net web app, and I have a question about nested Roles.
Say I have the following roles:
MyApp
MyAppUser
MyAppAdmin
MyAppSupport
For the most part, all users (MyApp) can access the app, but some functions will be specific to the other roles.
I want to declaratively restrict access to the web pages to members of the MyApp role.
[PrincipalPermission(SecurityAction.Demand, Role = "MyApp")]
I will check User.IsInRole or use the AzMan API to check for operation permissions within my code.
The users are assigned to the lower level roles (user, admin, support) and those roles are added to the MyApp role.
The problem is that when I check if the user is a member of the MyApp role, they aren't, even though the role they are in belongs to the MyApp role. Is the only way to check this is to recursively go through all the roles? That'd mean I cant use the declarative security, or to do so I'd have to add all users to the top level group as well (not ideal).
It sounds like you're expecting composite Role Definition (where a Role Definition is defined to include other Role Definitions) to be supported in the call to IsInRole(). I think you'd get the results you want if you used Group inheritance and Role Assignment instead.
In other words, rather than depending on IsInRole to follow the Role Definition for "MyApp" to determine that the Role Definition "MyAppAdmin" is part of that definition, create the inheritance using Groups instead, and then assign one or more groups to your Role Definition using Role Assignment. You could create an "Administrators" group, which might be a member of the "Everyone" group.
I'm really thinking that your role names are really better group names. A role signifies certain capabilities, not a classification of users based on their rights. That's what a group is for.
For example, suppose that most users (not admins or support) have read-only access to your app. I tend to call that role "Viewer" and I assign it the tasks or operations that allows users in that role only the ability to view, not edit, any data. I would assign everyone to that role (whether I do that with just one group or several doesn't really matter). The "Support" role allows users assigned to it to perform certain operations (or tasks grouping operations). Only some people would be assigned to that role (again, maybe they are assigned individually, or I have a group named "Customer Support Reps" -- doesn't matter).
In my app, I could check IsInRole("Viewer") and everyone who is a user will be in that role. But if I check IsInRole("Support"), only the people in the "Customer Support Reps" group assigned to that role would return True.
Not sure if this belongs here or on Serverfault.
I have a Sharepoint installation and several Active directory domains. In each domain, I have some Security groups.
I need to create Sharepoint groups that contain those Active Directory groups, but I need to inlude the actual users instead of just the security group. (So in I have Group G1 with Users U1 and U2, my Sharepoint group needs to contain U1 and U2 instead of G1).
Before I build something like this myself (which is rather straight-forward with a Timer Job and some Management forms), I just wonder if something like this is already built in to Sharepoint 2007? Or if they are existing solutions?
Googling brought only results about the normal AD<>SP Profile import, which works fine, but nothing about Security Groups.
This definitely isn't built into SharePoint. It may be available in a third party solution, however my guess is it would be an uncommon requirement so unlikely.
I would probably develop the solution myself. It shouldn't take long.
I would write a timer job for this (if you want to keep the AD groups and SP groups in sync).
Make sure all your groups are in 1 OU (to make for an asy stsrting point for an LDAP query), then iterate through all the security group objects with Directory Services in the TimerJob execute method. Then, iterate through all user objects in the group and add them to the corresponding SP group, remove users that are removed from the AD group from the SP group too.