A user is added to 2 different groups. 1 group is provided author access and another group is provided with editor access. First group has user role 'A' and second group has user role ' A,B'. What is the access and role the user would have?
The user would have the highest access level of all groups (in this case editor access) and all roles assigned to groups (in this case A and B) in database's ACL.
There is only one exception: if the user is listed with his own name in ACL then only these rights the user would have, no matter which listed groups he's member of.
The access levels are combined. However, Deny access takes precedence over Allow access.
See the docs for more info: http://www-12.lotus.com/ldd/doc/domino_notes/7.0/help7_admin.nsf/b3266a3c17f9bb7085256b870069c0a9/52f8492cea3792698525706f0065c44b?OpenDocument
Also, as the doc states it is helpful to use the Effective access feature within the ACL dialog to see exactly what the user access is.
Related
I'm using Odoo v8 and need a means to prevent certain users (either (preferably) in a sales team or in a user group) from accessing certain contacts (assigned to a different sales team) or the contacts at all.
I tried to achieve this via Record rules but don't seem to get this to work.
Users and user roles are critical points concerning internal security in OpenERP. OpenERP provides several security mechanisms concerning user roles, all implemented in the OpenERP Server. They are implemented in the lowest server level, which is the ORM engine. OpenERP distinguishes three different concepts:
user: a person identified by its login and password. Note that all employees of a company are not necessarily OpenERP users; an user is somebody who accesses the application.
group: a group of users that has some access rights. A group gives its access rights to the users that belong to the group. Ex: Sales Manager, Accountant, etc.
security rule: a rule that defines the access rights a given group grants to its users. Security rules are attached to a given resource, for example the Invoice model.
Security rules are attached to groups. Users are assigned to several groups. This gives users the rights that are attached to their groups. Therefore controlling user roles is done by managing user groups and adding or modifying security rules attached to those groups.
Users
Users represent physical persons using OpenERP. They are identified with a login and a password,they use OpenERP, they can edit their own preferences, … By default, a user has no access right. The more we assign groups to the user, the more he or she gets rights to perform some actions. A user may belong to several groups.
User groups
The groups determine the access rights to the different resources. A user may belong to several groups. If he belongs to several groups, we always use the group with the highest rights for a selected resource. A group can inherit all the rights from another group
Rights
Security rules are attached to groups. You can assign several security rules at the group level, each rule being of one of the following types :
- access rights are global rights on an object,
- record rules are records access filters,
- fields access right,
- workflow transition rules are operations rights.
You can also define rules that are global, i.e. they are applied to all users, indiscriminately of the groups they belong to. For example, the multi-company rules are global; a user can only see invoices of the companies he or she belongs to.
Concerning configuration, it is difficult to have default generic configurations that suit all applications. Therefore, like SAP, OpenERP is by default pre-configured with best-practices.
Access rights
Access rights are rules that define the access a user can have on a particular object . Those global rights are defined per document type or model. Rights follow the CRUD model: create, read (search), update (write), delete. For example, you can define rules on invoice creation. By default, adding a right to an object gives the right to all records of that specific object.
Record rules
When accessing an object, records are filtered based on record rules. Record rules or access filters are therefore filters that limits records of an object a group can access. A record rule is a condition that each record must satisfy to be created, read, updated (written) or deleted. Records that do not meet the constraints are filtered.
For example, you can create a rule to limit a group in such a way that users of that group will see business opportunities in which he or she is flagged as the salesman. The rule can be salesman = connected_user. With that rule, only records respecting the rule will be displayed.
Field access rights
New in version 7.0.
OpenERP now supports real access control at the field level, not just on the view side. Previously it was already possible to set a groups attribute on a <field> element (or in fact most view elements), but with cosmetics effects only: the element was made invisible on the client side, while still perfectly available for read/write access at the RPC level.
As of OpenERP 7.0 the existing behavior is preserved on the view level, but a new groups attribute is available on all model fields, introducing a model-level access control on each field. The syntax is the same as for the view-level attribute:
_columns = {
'secret_key': fields.char('Secret Key', groups="base.group_erp_manager,base.group_system")
}
There is a major difference with the view-level groups attribute: restricting the access at the model level really means that the field will be completely unavailable for users who do not belong to the authorized groups:
Restricted fields will be completely removed from all related views, not just hidden. This is important to keep in mind because it means the field value will not be available at all on the client side, and thus unavailable e.g. for on_change calls.
Restricted fields will not be returned as part of a call to fields_get() or fields_view_get() This is in order to avoid them appearing in the list of fields available for advanced search filters, for example. This does not prevent getting the list of a model’s fields by querying ir.model.fields directly, which is fine.
Any attempt to read or write directly the value of the restricted fields will result in an AccessError exception.
As a consequence of the previous item, restricted fields will not be available for use within search filters (domains) or anything that would require read or write access.
It is quite possible to set groups attributes for the same field both at the model and view level, even with different values. Both will carry their effect, with the model-level restriction taking precedence and removing the field completely in case of restriction.
Note
The tests related to this feature are in openerp/tests/test_acl.py.
Warning
At the time of writing the implementation of this feature is partial
and does not yet restrict read/write RPC access to the field. The
corresponding test is written already but currently disabled.
You can add a Rule for a group of users. I just made it and it's work fine.
Is there a way to combine access rights for a Sitecore item?
For example, I have a page that I would like to lock down to users who are a member of two different roles rather than just just one, and a user who has just one of the roles should be denied access.
I know you can have roles within roles but wondering if there was a simpler way to achieve this?
I'm using Sitecore 7.2.
If you are trying to check this in code, you can easily do so using
var user = AuthenticationManager.GetActiveUser();
return user.IsInRole("Role1") && user.IsInRole("Role2") ? "Granted":"Denied";
But if you are trying to achieve this in Sitecore Security on an item, then an AND of those 2 roles will be assigned. Ex: If I allow access to an item in Role1 but deny in Role2, the user with Roles 1 and 2 will have his/her access denied.
The simplest way to approach this is to define a new role with appropriate access rights and assign the relevant users to it, either manually or by script. That keeps your access rights transparent. You could code your way around the issue, but you could end up creating an admin nightmare, where it's near to impossible to see which roles and users have access to which items. E.g. what would you expect to see in the Access Viewer when looking at one of the roles, or at a user with one or both of the roles? There's a big difference between assigning access rights programmatically and evaluating them programmatically.
One way that you could achieve it via the Security Editor is by utilising Sitecore's Roles in Roles functionality.
Essentially you will want to create a New Role in the Role Manager that will contain the two roles, Role A and Role B. Select your New Role in the Role Manager and click Member Of button. In the modal click Add and select the two roles this New Role needs to contain.
In the Security Editor select the New Role and assign the read, write, create etc permissions to the required Items.
Now when users access those Items they must have Role A and Role B before given access - they will not need the New Role assigned to their account.
If you have a large number of roles to manage and combinations of those it will be very time consuming to manually create those combinations.
for example, 2 extranet roles in sitecore Role1 and Role2
Role1 is block access to item, Role2 - allow access.
I need to have behavior that revers default sitecore behavior:
5.3 How Access Rights Affect Each Other In Sitecore, every user and role can be a member of several roles. When a security account has
been assigned several roles, the access rights that the different
roles possess are added together. The security account is therefore
assigned the accumulated access rights of all the roles that it is a
member of. However, if a security account is assigned two roles and
one of the roles is denied a specific access right to an item and the
other role is granted this access right to the same item, the access
right is denied for this security account. In other words, deny
always overrules grant when access rights are accumulated.
Is it possible to do via some sitecore settings or etc ?
Thanks.
What is the behaviour you want then? If someone has both Role 1 and Role 2 - Do you want that person to have see it?
In that case you'll be better off removing inheritance on Role 1 in stead of denying access. Denying access basically tells Sitecore to start over from a specific point. Role 2 can then get the access again.
Have a read through this: Best Practices from TheClientView. The very first example sounds like what you're trying to achieve:
There is a role A that denies a write access to a “/home/contact us”
item.
There is a role B that allows write access to the item. There is a user AB that
should have power of both roles A and B. But due to explicit deny permission on
the item, the user won’t be able to get write access on it. When you break the
security inheritance it sets permissions into default deny state, which could be
overridden, by setting up explicit allow access on a role. But explicit deny
access can never be overridden by explicit allow access.
I feel ACL is like whitelisting, ie, give some users/groups some permission. Is this true?
yes
you can create list of user and where this user access to do some thing
also you can create list of group and assign access then create relation between user and groups
also see: http://en.wikipedia.org/wiki/Access_control_list
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.