It seems policies / permissions are directly checked against claims. How can ABP be used in an enterprise application that has hundreds of permissions?
It seems policies / permissions are directly checked against claims.
That is not true. Permissions are indirectly checked against these claims:
AbpClaimTypes.UserId by UserPermissionValueProvider
AbpClaimTypes.Role (role names) by RolePermissionValueProvider
AbpClaimTypes.ClientId by ClientPermissionValueProvider
For each claim, permissions are checked against PermissionGrant in the cache or database.
More about Permission Value Providers:
https://docs.abp.io/en/abp/4.3/Authorization#permission-value-providers
How can ABP be used in an enterprise application that has hundreds of permissions?
In most cases, grant multiple permissions to a role and then grant a role to multiple users.
(You can also grant permissions directly to user, since the permissions are not stored in claims.)
There is ongoing development to not use claims for roles, then hundreds of roles will be no issue:
https://github.com/abpframework/abp/issues/8620
Related
The goal is to get an access token with a custom set of roles.
My scenario is that I have an User Storage Provider SPI that looks into an Oracle DB for authentication. It also checks users permissions defined in other tables of that DB. I would set that permissions into the UserModel object returned by the SPI.
Now I would like to define in Keycloak (using the administration application) custom roles and configure them so they are included in the access token of the user depending on some rules over the user's permissions that I've set previously into the UserModel. The idea is to be flexible and allow to change the configuration between roles and the user's permissions found in DB.
I've read the theory about mappers and policies but I'm not sure how to manage it and I can't find an example that ilustrates the process.
I want to know if it's possible to create an Active Directory user account that confers no access or privileges to that user.. simply to authenticate a set of credentials..
As we are hybridised AD/Azure organisation, I want this 'account' to replicate to Azure through the connector.
The reason for this is that:
We manage all our users through AD so I don't want some accounts managed only in Azure.. it would be very confusing. Centralised managemnent and support is good!
The account would ONLY be used for authenticating users into Zoom via SAML2, or any another cloud service for that matter that can use Azure as an authentication service.
No capacity to access anything within our firewall.
Your ideas would be greatly appreciated.
Gus
It depends how you define "access". By default, the Authenticated Users group is able to read everything in AD, but not write. If you're ok with that, then you're done. Just create a user and don't add any access to it.
If you don't want it to read anything on the domain, then you'll have trouble. The Authenticated Users group is described as:
A group that includes all users whose identities were authenticated when they logged on. Membership is controlled by the operating system.
Since there is no way to not have a user be part of Authenticated Users, then you would have to modify the permissions on your domain to exclude Authenticated Users. But that may cause other issues for other users.
As far as I know, the most basic permissions that any user is created can also view other users or groups in AAD. If you want to turn off this basic permission, just set Restrict access to Azure AD administration portal to Yes, then the user will not have any access rights.
Go to azure portal->click Azure Active Direcotory->User settings
In the Airflow documentation under RBAC Security, it states
Airflow ships with a set of roles by default: Admin, User, Op, Viewer, and Public. Only Admin users could configure/alter the permissions for other roles. But it is not recommended that Admin users alter these default roles in any way by removing or adding permissions to these roles.
Let's say I want a User to be able to change their own password. Only Admins can do this by default but I could allow it by just altering their permissions on the relevant views. Is it instead preferred I create a new role with that permission? Or is this a bad idea for some other reason?
How can I give a new user only Admin Rights to one DNN portal?
Currently, we have two portals but I only want to give the users rights to the one portal on DotNetNuke.
What you've described, is in-fact how the "Admin" role works within DNN.
If you are used to the "Host" role, which does span DNN portals, I can see why you'd be confused.
Setting up an Admin user, or any other security role, will only be honoured on that specific portal.
If you want a user to have admin access over multiple portals - They will have to have separate admin accounts.
I would like to create a user similar to admin, but with restricted privs. The user would be able to create/read/delete objects under a certain DN in the directory, but not others.
Typically, the native server providing the LDAP service has an ACL model.
Within that system, you can create users with appropriate trustee rights/ACLs.
For example, in eDirectory, you would grant this new user object BCRDI rights to the container of interest, then have your LDAP app authenticate as that user.
In Active Directory you can do the same thing.
In Open LDAP you can do the same thing.
The specific details depend on the server providing the LDAP service. (I like others, hate saying LDAP server, since really they are not LDAP servers. They are offering an LDAP service on top of whatever database they store objects in.)