Let's say we have a web app that lets the user create "widgets". We have a new client that would like to control access to each widget with their organization's Active Directory, such that some of their users can view certain widgets and other users can edit other widgets.
What's the proper way to implement this? Should every widget have its own read group and modify group, and we let the client control the membership to these groups? Is there a better way?
Design discussions can be long-lasting and people nowadays prefer Agile methodology to keep making changes as per the new requirements to get the end refined product.
But, here is a one way in which you can implement this -
You will have one B2C(for new users) Login and one AD login(for organization users).
Then, you will have to use RBAC to have different views and features for different types of users(one B2C, 2 different users from AD) using claims and user properties for AD users. For eg, Airbnb has same website but different experiences for hosts and Users who book stays.
Related
I understand this is a really open question but I wondered what approaches you would all take.
Backstory:
Making a website that will have many different Roles that should have different access levels to the site.
Imagine a Role of Admin, Mod, Team Leader and Member. But there are say 3 teams with each of these roles within them. The Roles should only have permission level access to their own Team. all can access their own accounts and each others but only certain levels can change details as you go up. Admin is top level with full access, Mod can access say blogs and wikis, Team leader can manage the Team's details ect
What tools would you use to achieve this?
We are currently using AWS Amplify, Cognito and potentially AppSync.
Could i achieve this efficiently with IAM Groups or IAM Roles or AppSync?
Im new to all of this.
My initial thought was to grab the Cognito Group, Role and Tag Details when they login and store their TeamID and Tag/PositionID upon initial login and then do checks on the pages to compare the stores group and access levels and change the UI accordingly but is that the best way? Is there better free tools out there?
Thanks
Sam
Roles / groups are confusing.
Best explanation is you give roles to AWS services most of the time, and you assign real humans to a group.
If there is a dev or leader that has access to multiple different AWS projects, you can give them a role as well.
A majority of the time, roles are saved for Amazon services, like EC2 instances that need to access AWS services.
The majority of the time you put humans in groups. Unless the dev has an IAM account that is not under you. For example, if you are name#projectOne and projectOne is the root account, and someone else is name2#projectThree which is in a different part of your company. You could give them a role because their IAM account they are logging into is from a different root account.
Majority of the time, save roles for AWS instances like Ec2, etc. Just put IAM users in groups. If they are not under your root account, give them a role and then once they are in, they can get put in groups too, or can assign themselves into a group.
Don't give lower dev's roles, unless they are coming from a different dev team. If it is the same dev team (under the same root) just assign them to groups.
Continually check what permissions are being used by the devs in your group. Click on their name and then click on security advisor. If you see they aren't using a bunch of things (because it will show last day used...) then modify the group they are in, or create a new group for those specific activities and put them in that. AWS recommends giving the least access necessary.
I’ve been asked by a customer to find a way to collect all permissions for all app registrations in the customer’s AzureAD tenant. The customer has 1500+ App Registrations, so checking each manually isn’t an option. Most of these are redundant but the customer wants to review all of them to look for Graph API permissions that they’ve deemed sensitive. The problem is, there isn’t a way to export this info in the portal and Get-AzADApplication doesn’t give me actual permissions, just friendly descriptions of them. The customer would like the ACTUAL Graph API, such as Mail.Read.
I’ve attempted to script this with the assistance of a few more senior PFEs, but we’ve been unable to make any progress passing various properties between Get-AzAdApplication, Get-AzADServicePrincipal and Get-AzureADOAuth2PermissionGrant. We reached the point where we were able to get the Graph API permissions from the Service Principals, but the resultant permissions were in an unusable format.
If anyone has any suggestions on how to get this information into a concise format with (preferably) the Graph API permissions as mentioned above, I’d greatly appreciate it. I’d rather not go back to the customer and say it isn’t possible, as this is a new customer and I’d rather not say ‘No’ to my first task. 😊
Use Microsoft Cloud App Security for that purpose. This is tool designed, beside other features, especially for that purpose.
You open https://security.microsoft.com/ as a Global or Security Administrator, then you have quick overview on central place:
This will bring you to the MCAS portal, where you have solicit view on all applications with a rating, according to Microsoft standards for "Highly priviledged" access:
A direct view to applications, which users are using these applications, what permissions are granted. It even has filtering capabilities allowing you filter apps based on access level sevirity or even some Graph permissions - like Access e-mail on behalf of the user.
Your customer should really be using the Microsoft Security Center and monitor their security score: https://learn.microsoft.com/en-us/microsoft-365/security/mtp/overview-security-center
Then looking at MCAS: https://www.microsoft.com/en-us/microsoft-365/enterprise-mobility-security/cloud-app-security
You can use this script to list all delegated permissions and application permissions in Azure AD.
The key of the script is Get-AzureADServicePrincipalOAuth2PermissionGrant -ObjectId.
Based on my test, the permissions in the result is in this format: email offline_access openid profile User.Read.
I think it's what you need.
I am playing around with the Azure Document DB because we are planning to create a multi tenant application.
For the multi tenant application, my idea would be to create 1 db user per tenant. This gives me the advantage that tenant data would be completely separated: When creating a document, a permission is added to the tenant user. (Read/Write) This means when querying, the data will always be scoped to the current tenant.
I was also playing around with 1 DB user per end-user. But this gives me a lot of overhead to manage the security on documents. When user x from tenant z adds a document, all users from tenant z need to be updated with an extra permissions for that document. This seems unfeasible.
Is my assumption correct? Or would you suggest another approach for this? Are there any downside to this approach?
For our multi-tenant solution we chose to not use DocumentDB's controls at all and do all of our authorization in the middle tier mostly because we wanted it to be predicate based and different per tenant. That said, your approach of using DocumentDB's authorization capabilities at the tenant level makes sense. That will give your tenants added assurance that other tenants can't see their data.
My one thought is that if you have some cross-tenant functionality (maybe in the form of tenant groups) then it would break the model so you may want to consider that.
I assume tenants are hundreds and users are thousands but whatever they are, you should confirm that the DocumentDB authorization capability scales to that level. Maybe one of the DocumentDB product managers that monitor this can chime in?
In my application, a User is assigned multiple Roles, and a Role is assigned(granted) multiple Permissions.
So in my code, I never check against a Role, but always against a fine grained Permission.
Here is described why I think Permissions based access is better than Role based:
https://softwareengineering.stackexchange.com/a/299732
Within Azure AD, I can assign roles to a user.
But I see no way of creating Permissions and associate them to Roles, so I guess this part must stay in my app ?
Then how should I link the Azure Application Roles to my app's Permissions ?
My assumption is I need to build an UI for doing this, using the Graph API to retrieve the list of roles defined in Azure for the application.
If that is the case, then I don't see much benefits using the built-in roles function in Azure vs keeping the role definition in my app...
Am I missing something ?
The key point of using Azure AD claims is to keep users information in the Active Directory rather than in the application.
In you case, you need to create permissions mapped to roles in your application.
Then theses roles can be mapped to Azure AD AppRoles or Groups.
I suggest you not to map directly users to roles.
If you deals with Group, you don't need to add/remove users to/from applications: Roles and permissions are inherited from groups users belong to.
Mapping directly to Groups
For the moment, it would be my preferred scenario. Users are assigned to groups and your customs roles are mapped to these groups.
When you create a new user, you just need to add it in some groups and there is no action required in your application (same things when you delete the user).
If you are not afraid of preview (and have an Azure AD Premium license), Azure Ad provides a way to dynamically assign users to group.
Just keep in mind that for the moment nested group memberships aren't currently supported.
So if a Group A is in Group B and Group B has some permissions in your application, Users from Group A will not have permission inherited from Group B.
Mapping Groups to application roles
This option seems to be an overkill because it requires one more step: Map Azure Ad Group to Azure Application Roles and Map theses roles to your custom roles.
You need to implement all this logic using the AAD Graph API and your UI will be more complex.
Only reason to use this option in your scenario is if you have a large directory with lots of groups and applications : If a user is in more than 200 groups so the Jwt token returned by the Azure AD will not contain the groups and you will have to query one more time the Azure AD to get the user groups (see).
In this scenario, it could make sense to map groups to application roles because when a user authenticates to an application, Azure Ad will always provides you the roles of the users (or the roles of the group that the user belong to)
you can find interesting code sample here:
active-directory-dotnet-graphapi-console.
At this point in time, Azure Active Directory application roles are meant primarily for the scenario where each user can only have one role and thise roles are mapped to a simple authorization model.
While it is technically possible to support multiple roles per user, that can only be managed via the Graph API and would require you to build a UI for your user admin / users to manage.
As you've noted, your scenario is more complex than this with multiple roles per user and multiple (potentially customizeable and overlapping) set of permissions.
Given these two points, your approach of implementing all of the authorization yourself is a sound one.
Check out this article which outlines in more details the authorization scenarios Azure AD is best suited for:
https://azure.microsoft.com/en-us/documentation/articles/guidance-multitenant-identity-app-roles/
I am currently working on a project where i have to make a Hotel Booking Application. There will be general user who will browse through available rooms and will have to login to book. Hotel owners will have account to manage their inventory. And there will be admin section to manage the app. I am confused about what is the best approach to scale this kind of app in Laravel. Because each kind of account will require different type of authentication. I have thought multitennent approach but doesn't seem like This app falls into this category. Thanks in Advance for any help.
For this scenario, you can implement Role based authentication.
You need to create 3 roles.
Hotel Owner
Application Administrtor
General user.
Based on the role, you need to provide access. If you haven't developed Authentication system, you can use Entrust along with Confide.
Entrust provides a flexible way to add Role-based Permissions to Laravel4.
Confide is an authentication solution for Laravel made to cut repetitive work involving the management of users.