the ACL evaluation rules I found are
Allow rights have higher precedence than deny rights.
Group principals are evaluated in order, both within the hierarchy
and order within a single access control list ie on the same node
(CONCURRENT).
This list is then scanned bottom-up until the first appropriate
permission to apply to a page is found
so when a user is part of both group which rule gets applied when deny permission is at bottom of list? the first rule or third rule?
In case of group-hierarchy how is ACL created according to group hierarchy or in order we give the permission to the group-principals?
It depends on the sequence of allow/deny rep policy. If the deny is placed after allow the user will not have access. The best practice is to always set a deny for all followed by selective allowed permissions.
Sequence matters a lot!
The one which is at the bottom will be applied. If deny is placed after allow then no access will be provided to that user. Similarly if allow is placed after deny then permission is allowed. AEM best practice is to first deny for all then allow permissions selectively & accordingly.
Related
I have 2 users, one with less than 30 roles and one with 400 roles. When I login with the 30 role user, I can reach the redirect URL without issues. But when I log in with the 400 role user, the request to the redirect URL doesn't complete. If I reduce the number of roles in the 400 role user then it will work. So, is there a way to disable passing roles in the java access token or increase some limit somewhere that's causing the failure?
I would suggest to focus rather on roles reduction/optimization than forcing the transmission (raising limits) over the maximum number of roles inside tokens (or anywhere else).
Some interesting questions (among others) to start with:
Which protected resources am I going to serve?
What am I trying to protect? and what are the associated risks? (build a Threat Model)
How do resources are served by each application? and how are they distributed among my applications?
What kind of resources are they? How can I group them? Which sets are identifiable? or what are the relationships between them? What actions are possible against all sets of resources?
Who are the users of each application? How will they interact with my resources? Which flows are sensitive?
What roles can I define for all my resources?
Which role can apply to each application, resource type or set?
What kind of user groups can I create?
Do I need additional attributes or claims for each set of roles or users/groups?
I firmly believe that if you answer all these questions you will end up having a bunch of roles instead of hundreds. Think security by design and follow principle of least privilege.
Focus on your use case
Now as far as I understand, your blocking point is that you are assuming that each resource is unique, sensitive and requires its own permissions, and consequently a role definition. While it may be true in some cases, in most other cases it does not mean that you have to use the token roles/scopes/claims to secure your assets deep at the resource-level. I'll try to illustrate this sentence by an example.
RBAC and authorizations example for your use case
Let's assume that:
you have millions of sensitive resources to serve
each registered user of your application has access to a (different) set of these resources.
your resources are splitted into, say, 3 categories (e-books, videos, musics).
each resource can be downloaded, uploaded, deleted.
your application will meet unregistered users, registered users, contributors and administrators
registered users will always have read access to resources (not a single action will ever allow a modification)
contributors are particular registered users who can perform special actions including modification ('upload', 'edit')
contributors and administrators may have access to various administrative parts of the application
your application will evolve by serving additional categories of resources in the future and new actions will be available to users later (such as 'flag', 'edit' or 'share link').
Then first things first:
organize your resources accordingly by serving them behind categorized paths such as: .../myapp/res/ebooks, .../myapp/res/videos, .../myapp/res/musics
identify your resources via UUID such that a resource may look like: .../myapp/res/ebooks/duz7327abdhgsd95a
Now imagine that your business risks or at least the greatest risks you wish to avoid are:
unregistered users having gaining access or rights for any part of the application or resource
uncontrolled registration process (robots, spam, no mail verification, fake users, ...)
registered users gaining illegal privileges (unauthorized actions, access to other categories, illegal administrative rights)
discovery of available resources by any mean
You will note that I voluntarily didn't listed:
registered user having illegal access to certain resources. For example: maliciously pointed/provided by an existing user.
This is because it is not a high risk as you may hold contact information about registered users as well as log activity and actions, quota or requests throttling, and you may be able to ban them or start legal action against them. Your registration process is also assumed robust and secure. Nonetheless if its considered a critical risk you can address this with extra mechanisms (cf. suggestions at the end). But never will it result in adding extra roles, such as one per resource, as it does not fit in any security model.
That being said, finally, here are the roles and authorizations scheme you may come with:
SCOPE / AUDIENCE
MY_APP
ROLES
USER
CONTRIBUTOR
ADMINISTRATOR
CLAIMS / ATTRIBUTES
CATEGORIES
ACTIONS
--> POSSIBLE USER GROUPS
USERS
Roles: USER
Claims: CATEGORIES(variable), ACTIONS('download')
CONTRIBUTORS
Roles: USER, CONTRIBUTOR
Claims: CATERGORIES(variable), ACTIONS('download', 'upload', 'edit')
ADMINISTRATORS
Roles: USER, CONTRIBUTOR, ADMINISTRATOR
Claims: CATEGORIES(*), ACTIONS(*)
Following this model, assigning the correct group to each registered user will provide high-grade security by mitigating/controlling the main risks. As claims/attributes are defined in the token(s) (managed and signed by Keycloak) then you can trust this information in your application and serve your resources accordingly and safely. There is also no risk of illegal access or discovery of resources as you are using UUIDs, only registered users having had access once to a resource will know it and registration with appropriate category access will be needed for another user to access it (to only be able to read it basically). Of course you may store in a database the list of resources to which each user has access to, raising the overall security to a very high level.
However, if the latest is not enough you may also implement rolling UUIDs or temporary links for your resources when served to users. To go farther you may also define groups and masks for your categories, resources and actions.
In fine, in this example I made use exclusively of token claims to define roles (common claim), categories and actions (custom claims). In terms of security the authentication and identity will be the first-line security followed by roles then categories, actions and stored list of resources per user (db).
Other alternatives are obviously possible, its just an example. Still, I hope it helps!
To fix this problem you should start from defining client scope mappings for each of you applications (e.g. oidc clients). Main idea of this facility is that even if your user is super duper admin with all existing roles, all of his roles actually don't required for any particular application. For example client foo which defines following roles:
foo_user
foo_viewer
to perform its security logic need to know only whether currently logged user has foo_user or foo_viewer, but it doesn't care about has this user roles bar_user or bar_admin from application bar. So our goal is to make Keycloak return for any client access token with only valuable set of roles for this client. And roles scope mappings is you friend here. You can set for client foo scope like:
foo.foo_user
foo.foo_viewer
bar.bar_admin
and now even if logged user has role "bar.bar_admin" this will not go to access_token since client foo doesn't take this role into account. After applying some scope settings you can test them at 'Clients -> $CLIENT_OIDC_ID -> Client scopes tab -> Evaluate sub tab.
As for you case with 400 roles, i'm quite confident that none of your application requires all of 400 roles, so precise scope configuration for you apllications can drammatically reduce access token size.
But if i'm mistaken and you really have an application that rely on large amount of roles you should look into you runtime settings.
For example if you run keycloak behind reverse proxy like nginx large tokens may not fit in default HTTP parameters buffer size (afaik about 2-4kb) so you have to increase it via appropriate nginx configuration option. Another example is tomcat which has about 16kb as default HTTP header buffer, so if you send request with very large access token in Authorization header Tomcat may not handle this request properly.
I have checked the docs from Microsoft for AzureDevops and I understand how to manage permissions for a branch.
What I would like to know is if a user is automatically added with Edit Policies permission to Allow as he creates the branch (assuming a normal user not admin, and he's not inheriting this permission) ?
If the answer to the above question is yes, then is there any case when a second user could be added to the list of branch permissions automatically ? without an administrator adding it explicitly ? I couldn't find this in the docs anywhere.
*picture from msdn
Yes, for each branch's permission setting, you could directly manage that user's or create a group then add that consultancy in the group, manage the group's permission.
In other words, without adding it explicitly, the user B could also be added to a group.
You just need to make sure that you are not part of any groups that have the complete privilege Denied.
In Azure DevOps, Deny trumps Allow.
Unless you're a member of the Project Collection Administrators group on your organization, membership in a group that explicitly Denies any permission will deny your permission, even if you are in another group that explicitly Allows you the permission and even if you as an individual user are granted Allow on that permission.
We usually add developer to Contributors.
For the Inheritance part, you could turn on your inheritance and clear explicit with single click for each branch which have explicit permissions.
After this, Contributors Group in other branches will totally inherit the permissions set by root path of your repo/workspace. For example, if root path are Allow, your branches should be Allow(inherited), if it's Deny, your branches should be Deny(inherited).
If a permission isn't directly allowed or denied for a user, then it may be inherited in two ways.
Users inherit permissions from the groups to which they belong. When
a permission is allowed for a user directly or through membership in
a group that has that permission, and it is denied, either directly
or through group membership, the permission is denied.
Members of Project Collection Administrators or **Team Foundation
Administrators** retain any allowed permissions, even if they belong to
other groups that deny those permissions.
Object-level permissions that are assigned for nodes of a hierarchy -
areas, iterations, version control folders, work item query folders -
are inherited down the hierarchy. That is, a user's permissions that
are set at area-1 are inherited by area-1/sub-area-1, if the same
permission is not explicitly allowed or denied for area-1/sub-area-1.
If a permission is set explicitly for an object, like
area-1/sub-area-1, then the parent node is not inherited, regardless
of whether it is denied or allowed. If it's not set, then the
permissions for that node are inherited from the closest ancestor
that has the permission explicitly set.
More details please take a look at our official tutorial here: Inheritance and security groups
I need to give someone access to create work items ONLY. They are a 'stakeholder' user. Currently I cannot restrict them from seeing Variable groups OR Task Groups. I cannot see any deny permmisions and the person is in no other groups. I added them to an organization group with DENY permissions in all 4 Pipelines permissions. Still the user can see them
I added them to an organization group with DENY permissions in all 4
Pipelines permissions. Still the user can see them
That's caused by that the permission listed here used to restrict the build view, such as build definition and etc. But, Variable group and Tasks group does not belong to build, they just be linked/called into the build. Set the View build resources as deny could not restrict these objects' permission. For example, Azure Key Vault's view permission could not be restricted by deny the permission of build. It just can be changed in Azure portal.
These function( such as variable group, task group, key vault and etc) which be linked/called into build called object. To modify its permission, you must go objects' security page to change it.
Since what you are focusing is Variable group and Task group, unfortunately, viewing these objects belong the basic permission of Stackholder and could not be restricted in security configuration.
As you can see that there's no permission to restrict View. So, restrict stackhokders view it could not be achieve.
For security, I think you can change their level as Project reader to restrict them do change to them.
I'm working with Shopware.
I've added a new attribute "proxy" to the s_core_auth table for each user in order to show the ability to get access to the Customer Module in the backend, so that if a user is not selected as "proxy" he/she won't be able to make changes in that module.
I need help to understand what I need to write in my plugin's code (maybe having only a Subscriber file.)
I'll be very grateful!
Adding a custom column to the s_core_auth table is not a good idea. What you're trying to achieve can be done with user groups and group rights. From the Shopware Documentation:
With User administration you are able to create new users in the backend and control access rights to areas, modules and plugins in accordance with certain group policies that you define per ACL (Access Control List). Within the ACL you have the possibility to control precisely which user is able to perform which activity. Thus, it is possible to assign certain reader rights to an administration group without granting them authorization to edit or delete.
You can find instructions for User administration inside the Documentation.
I have a small question related to granting access to multiple sites in Sitecore 7.5.
Let's say I have a website named as website_1 and another website named as website_2 in my Sitecore environment. Now I have created two roles. One role named as r_website_1 gives access to website_1 and another role r_website_2 gives access to website_2.
In r_website_1, only access to website_1 is granted and access to website_2 is denied. The same goes for r_website_2 but for
website_2.
Now I want to give read and write access to user_1 for both websites. What I did was went to User Manager>user_1>Edit>Member Of and then assigned both roles.
What I noticed that the user_1 only gets access to one website. it seems that both roles are countering each another. For example, the denied permission for website_2 in r_website_1 is conflicting with allowed permission for website_2 in r_website_2.
May I know what's the fix for this problem?
Thanks in advance,
Vaibhav
Deny permission always has priority. You cannot remove by simply adding another role with allow access rights.
Instead of using deny you should break the inheritance of chosen access right for the role1 for site2 and similarly for the role2 for site1.
Here is a quote from Sitecore Administrator Security Cookbook:
We recommend that you use inheritance whenever possible to limit the access that roles have to the items in Sitecore. Using inheritance instead of directly denying access rights to items makes it easier to manage the security system.
And you can read about breaking inheritance of access rights in Assign access rights to a security account document.