Hi i have a group system and i'd like to add some security to it.
Users can belong to multiple groups and id like to know the best way to authorize people to see the groups only if they are in it. If they aren't i want to redirect them to a another page, which is different according to the group.
For now i created a service but i have to use it in every controller...
I've heard of multiple things but not sure if they are appropriate for my situation.
Thanks for your help
There are several different ways to do this depending on the approach/complexity. Here are a few:
1) Use Symfony ACLS. When a user is added to a particular group, you can use the symfony ACL system to grant them view access to that group, and then later check isGranted() against that group to see if they have view permissions.
2) Create a custom voter
http://symfony.com/doc/current/cookbook/security/voters.html#creating-a-custom-voter
3) If the number of groups is limited in number, you could even use Doctrine query filters to automatically add a where clause to all queries where the group_id is in a list of allowed groups for that user. You can bypass this for all admin users. http://doctrine-orm.readthedocs.org/en/latest/reference/filters.html
Related
Can you add a user to multiple groups in one login?
No. A user can only belong to one group max. In the UI you can only select one and via API you can only specify one group_id.
Yes. You can add a user to multiple groups at a time provided your application separates your Authorization logic.
For eg, If you have 3 groups i.e., Customer, Manager and Administrator then the customer must have a different login interface where only customers can login, the manager must have a different login interface where only managers can login and so on. This can be achieved but it consists of lot of code related tweaks to be done.
But the recommended approach is that to assign a user to one specific group and manage the permissions at group level.
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.
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 developing a Symfony2 app which involves users with hierarchical roles. Right now i can register, recover and login into the application without issues as i've implemented roles and users as described in Symfony2 docs.
At that point, i've developed some CRUD's in order to be able to manage objects in the application but in the current implementation i must check current user roles in order to let him or not run "selected" actions. I mean, in each controller i get security context, then user object and check permissions then sometimes i need to check the current user is the owner of the data - i.e if an user has clients i need to check url passed variables/id/whatever are owned/belongs the current user - and then deny access or not.
So, as far i'm used to and feeling comfortable developing the application as mentioned above i'm wondering is there is a better approach or a Symfony2 approach where i can manage roles and data in standard or more understanding way so future developers doesn't need to go through each if or check inside controllers+actions. I also would like to note i would be able to customize how data or objects are fetched or loaded so i can optimize sql's run in background.
Symfony ACLs is exactly what you need. You can assign access rights (i.e. OWNER, EDIT, VIEW etc) to a single user or assign to all users with a certain role (or both).
If ACL is too complex for your needs, than an alternative approach would be to use a custom Security Voter.
We want a policy whereby permissions must be managed through sharepoint groups. We want to allow site owners to add and remove users from groups in order to manage their permissions to resources, but we don't want them to be able to create the groups or to add user's explicitely to the resource. Is this possible? I don't see any permissions that relate to restricting explicit access to a resource as opposed to access via a group, but I could be overlooking something.
No, this is not possible out of the box. Either a user is able to manage permissions or not, there is no more granular settings to only allow managing in groups.
Unfortunately there also isn't an event receiver you could use e.g. PermissionAdded or PermissionModified, so the only way for you to check these things would be to write a timer job which checks every X minutes whether anything has changed you didn't want to change. Or another possibility is to not allow users to manage permissions, but write your own permission manager which only allows working with groups. Then you could use RunWithElevatedPriviliges to perform your actions.