As default, when a user belongs to multiple roles, the more restrictive setting prevails.
Refer to this scenario: I have twenty users and I want to grant the access to one particular module (i.e. Ticket) to only one user. For the default logic, I should assign to nineteen users a particular role that block the access to that module.
I think that is more intuitive if there is a simple way to alter the ACL system so that the less restrictive setting prevails. In this way I could assign a role only to the one user that I want to guarantee the access.
So, the question is: how to accomplish it?
There isn't a way out of the box. There is a solution called SecuritySuite where it works exactly the way you want. If they belong to multiple roles then the most permissive rights are applied. There is a global setting to turn it back to restrictive as well.
Related
Is there an easy way to confirm that none of our projects have VIEW access (or higher) as the default role?
We want to give a handful of external contractors very limited access to specific datasets, but I'm worried that we have historically set up projects with different access controls; from before contractors were going to be onboarded.
You could make a new test user and on the /projects page, filter by role to see if the fresh user (who you don’t add to any Multipass groups) has any roles.
I need to set up user permissions within the same table, based on the value of a field. I know that this is not directly possible in Access but a post on Allenbrown.com points to a way of doing this see here. I'm not proficient in coding so I'm hoping that I can get some directions from you. Here are the details:
I have two tables in the database, a parent one populated via a form and a children one populated via a subform. The parent contains companies and the child contain subsidiaries of those companies. In the child table, I have a field called "Domicile" and I want to discriminate user access based on that. Because the database will be used by a variety of people worldwide, my plan is to create user groups based on location and allow users to edit (or add) information based on a match between their location (as specified in the group) and the domicile of the subsidiary. For example, a person in Europe will only be allowed to edit data for subsidiaries that are in Europe, even though companies from other domiciles may be stored in the same table.
I'm looking for some guidance here as well as suggestions as to how you think may be done most effectively. I'm not partial to this method, that's just something I came up with to put some logic behind what I'm doing.
Thank you so much!
The important thing to note in Allen's description is (emphasis mine):
Assuming all updates are performed through forms, the Current event of the form then locks the fields based on this property.
There would be no practical, bulletproof way to prevent users from viewing and altering any data in the table(s) if they open the back-end database file directly.
Since you are asking for advice on how "[row- or column-level restrictions] may be done most effectively" the first issue you need to address is how "effective" those restrictions really need to be:
If you can accept that these will be "soft restrictions" (really a matter of convenience to the user so they don't accidentally alter certain records or fields while using the forms), then Allen's approach might be sufficient. (If so, then follow Allen's instructions as best you can and ask new question if you need help with a specific aspect of that implementation.)
On the other hand, if you need "hard restrictions" (serious protection against mischievous or malevolent user activity) then you'll have to employ a different database back-end -- something like Microsoft SQL Server -- with a richer set of security tools for you to use.
I am looking for an example or information on row level security for PHP and MySQL. I have done the basic google reasearch, I have read all the posts / articles about using views and adding fields to table to specify what user has the right to view the object. Those example are fairly simple and would require lots of configuration / maintenance.
Here are a few real life examples of what i am looking for:
Clients data, allow to configurer what user or user group can view all or parts of the client file. This must be persistent for all the application features including reports and dashboards.
Employee files, give access to immediate supervisor and HR to an employee file without having to reconfigurer the access rights when supervisors change.
I think this should be handled directly from the database layer, but could also be applied to other resources for examples, uploaded documents.
I'm hinting to some sort of "filter" that I could pass my data into so it could be filtered.
Any interesting links to articles or frameworks that have implemented this with success would be greatly appreciated.
Thanks.
You would need to use MariaDB to do this, as MySQL doesn't do ROLEs, though you might be able to use GRANT PROXY to accomplish what you want in MySQL.
I think that different "tenants", i.e. paying customers, should be in different databases to avoid leakage. You can use scripting to automate this.
But if you want intra-company row-level security, you can accomplish this with an extra column per table and some views and triggers.
create a table with an owner column. Use an insert trigger to set owner to the current user. REVOKE all privileges on the table.
create a view WITH CHECK OPTION on that table that checks that current user is in a role that matches the owner. GRANT all privileges on the view.
Example:
create user `pointyHead`;
create user `dilbert`;
create role `manager`;
create role `minion`;
grant manager to pointyHead;
grant minion to dilbert;
grant minion to manager;
Not sure if there is a function to check if user is in role, but you can always use information_schema.applicable_roles.
You can use column-level grants to give different column permissions to different users. http://dev.mysql.com/doc/refman/5.5/en/grant.html#grant-column-privileges .
I am developing the application in which i have a super user concept. Super user is the user who has all the access for the application. So what my initial thinking is in user table the user with id 1 will be my super user. but how safe is this in terms of security concern ? is there any other logic which i can use to define super user ?
I have done more emphasis in coding side. I also implemented the roles and other access permissions, But what i need to to do is something like ghost user. Whenever he logged in he could be able to access everything like he is a father of application. for his access i shouldn't need to check any role conditions or access condition. is it possible ?
Thanks.
Why not work with roles? Make a column in your user table where you have 'SuperUser', 'Admin', 'ReadOnly',... Or perhaps just 0, 1, 2... and match it with a constant/enumerable in your code. Now you can easily change your super user, make multiple super users, give someone temporary super user rights, define other roles...
From the database point of view it is valid to define two or more users and grant more or less permissions to them, work with roles etc.. But as you said - it's about the application. So in parallel to the database security you need to consider application security in terms of:
which user may get which functions, menu items, web pages etc.
how can this be configured and parameterized, etc.
I personally put a bit more emphasis on the application side and less on the DB side. So thinking of e.g. PHP + MySQL, I have 2 DB users (operator, admin), but a database table within my application for each (application) user, assigning to them the operator or admin login for the DB and defining which parts of the application they get.
As a complement to the other answers:
Don't forget you could create users and grant/revoke permissions at DB level. I would not push for a 1-1 mapping between your application users and the DB users, but you could use that to implement "roles" and enforce permissions at DB level as an extra level of protection. This might be especially interesting if you have some users with "read-only" and/or "anonymous" access. This would prevent "escalation of privilege" due to a bug in you application code.
Super user is the user who has all the access for the application. So
what my initial thinking is in user table the user with id 1 will be
my super user.
In the Unix tradition, super-user is generally ID 0. This might improve code (maybe) and more important make it more understandable by programmers familiar with kernel/security coding.
But what i need to to do is something like ghost user [...] for his
access i shouldn't need to check any role conditions or access
condition. is it possible ?
I don't think this is a good idea to somehow "deactivate" all your security checks for one particular user. In order to improve maintainability and not clutter the code with permission-checking, as of myself, I would encapsulate all the code that need to check permissions in wrapper functions or objects, then I would use that wrapper in the rest of the application. Based on that, and if you implement "roles" at application level as someone else suggested, handling the "ghost user" shouldn't be too much of an issue.
I am making a semi-simple web application for my mother using php, mysql, and javascript.
She is a teacher, and this wil allow her to manage various components of her lesson plans.
For each component there is a table, and for each component that can contain another component there is another table that holds the relationship. (That table type has two columns each has a foreign key to the related tables)
I am nearly done, but she now wants to allow her friends to use this, I don't care too much about sql injection, but I would like to implement User Control so that only users that create a component can view and edit that component.
I also want them to be able to make public components, so that users can copy components to their own dataset.
My question To implement the user control should I have each user have there own database instant, or should each table have an owner column and column for public/private status, or is there another alternative that I have not thought of.
An issue that I see is that it would require additional mysql query when creating the relations between components because I would need to check that both components user tag matches the current user.
Any feedback/suggestions are helpful
Update The only people using/accessing this will be other teachers, that will be developing their own lesson plans
I would certainly implement this within the same database. Having a different database for each user is not a good solution in this case. Think, for example, how you would build a search function if each user's data is in a separate database will clashing UIDs. It would be a nightmare. Separate databases work where each database serves a separate application and there are precisely zero relations between the data in different databases.
So that brings you on to how to implement it. This will depend on your model. Will each lesson plan only ever have, for example, one and only one owner? If so, then adding that info to the components table might work. Or else you might need a separate table to define ownership and hence access to the different components. Either way, I would make sure the access logic is decoupled and encapsulated in your application to make sure you can change it in the future. Imagine for example you start with a simple, single-owner model but the site grows and grows and soon groups of people all need ownership/edit access to components.