I have been reading about ACL and it is quite interesting but I am not sure if ACL is a right tool for my new backend system.
I want to restrict certain features from User Groups and Roles, for example:
"Processing" group can see a category dropdown but it will be hidden from a "Sale" team.
"Processing" group a see a few options in a category dropdown. Admin group can see everything.
If I add a new group called "Training" - I would like a "Training" team to have access to
a category dropdown.
Is ACL right tool for this? If so - how can it be done.
Access control list - list of permissions attached to an object. It specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects. - wiki
So it fits exactly to your problem.
Create actions, users and then just set actions for the users. Or create groups and set the actions for the group and then put the users to specific group.
ACL - access control lists - is a good starting point but you probably want to look at more advanced authorization models for instance role-based access control and later attribute-based acccess control. NIST has defined these two models extremely well:
NIST RBAC: http://csrc.nist.gov/groups/SNS/rbac/
NIST ABAC: http://csrc.nist.gov/projects/abac/
RBAC and ABAC will scale better than just ACLs.
Related
The current ACL of phalcon is managing access between roles, resources and its actions. For example, if we want to allow specific role into specific resource :
$acl->isAllowed("Guests", "Customers", "search");
This check if role called "Guest" can access "Customers" controller for action "search".
In my scenario, we also have "Role Level", for example, Admin can access all modules and controllers, but, to modify the contents, an Admin should have minimum Role Level 2. To gain access to modifying website configuration, an Admin should have Role Level 3.
In addition to role level, we also want to assign which models a role can have access to. For example, Mr. A and Mr. B both are Admins and have same levels. But, we decided only to allow Mr. A to access "Accounts" models while Mr. B can have access to "Accounts", "Personnel", etc.
Here are my questions :
Does phalcon ACL support roles and levels ? Or, should I just create the custom validation?
What is the benefit of using ACL compared to creating similar validation functions?
If I have to create custom validation, where should I put it ? In the controller, or in the dispatcher ?
Thx
At the moment Phalcon does not support Role based ACLs. You will have to do something yourself to cover this. The feature has however been asked for and it is in the long list of NFRs for the project :)
The way I would go about it is use a combination of Phalcon functionality and custom programming. I would add everything to a base controller in the beforeExecuteRoute function so that whenever something is to be dispatched ACL is checked.
In a similar project to yours, I created two tables in my database:
Groups
------
group_id <- 2
group_name <- Admins
and have an ACL table that maps all actions to a group like so
ACL
---
group_id <- 2
acl_controller <- Customers
acl_action <- Search
You can easily extend this to have a collection of controller/action pairs to map to a Role. From there you can just create a simple function that would load the role based resources.
It is a bit of a workaround but it works.
I want to provide specified actions for different role in Symfony 1.4 project.
Project contains several database tables which values can be modified only by certain roles.
For example, an administrator gains access to CRUDs for all models.
Another role (let it be a consultant) can only retrieve (not modify or remove) results from specified models (not all).
How can I support such a feature in symfony?
I assume that roles for the project will be specified in advance.
One solution I was thinking about is creating modules and actions for each role separately (crud panels + one logging interface), but it sounds like a huge job.
Just wondering what the smarter way is.
I think the best way to achieve that is definitively credentials (it is for sf1.2 but ok for 1.4).
I recommend you to use sfGuardDoctrine to use some groups with associated permissions (which are credentials). You define a group admin, consultant, etc .. You associate some credentials, like modifiy, remove, create, edit, etc ..
And then, every time a user will log in, it will automatically have defined credentials (associated to him or by his group).
After, you have to check for every action if the user has can perform it:
if($this->getUser()->hasCredential('modify'))
{
// authorized action
}
Here is some more documentation for sfGuard (related to sf1.0 but it is good to understand how it works).
I am creating an web application and I at the point that i am starting to make backend choices. Now there are a lot of ways to go with this, so I am looking for some good points and back practices.
Some of the question i have involve:
Should i make a seperate table in the db for admin users
Should i extend make some classes to load the admin data and the normal data, or make seperate classes for the admin section
Where can i get some information on making different types of users
Just some best practices for a backend
My application is written in PHP with an MySQL database.
Keeping a separate table for admin users is nice, but only if those admin users aren't "regular" users as well - otherwise you'll step on your own toes trying to keep usernames/IDs unique but somewhat connected.
A couple things to consider:
Apache authentication (or Windows accounts on IIS) for admin users. Separate system entirely, but allows for overlap - a regular user can be a regular user, but they can't access any admin functionality until they authenticate through the browser. Works fine if you only have a couple specific kinds of user role (e.g. member & administrator only).
All users in one table, but with roles and permissions separate. This is the most flexible because you can get as granular as you need. For example, any user can "post comments," while an admin can "delete comments" and "ban users," but a moderator can only "suspend comments" and "mute users." As you add new features, it's simply a matter of implementing some new permissions & assigning them to the roles. Drupal's access control does this really well, worth a close look.
A good way to do it is to add a new field in the users table for 'rank' in order to differentiate between regular users and staff members, and possibly between the different staff member levels such as moderator, admin, etc. if you need it. Because an administrator should be able to perform all functions that a user can. Use
class Admin extends User { }
if you want to add additional functionality specific to staff members.
As for backend functions, that depends on how your site is set up. If you're using a framework, you can just add new functions to existing controllers and restrict access only to users with a certain rank.
For example, you might have a controller for ForumPost objects, but calling the ForumPost delete() function would require the user to be a forum moderator.
If you're not using a framework, you'll probably have to make your own pages for each backend function you need.
How can i manage user permission?
i need a fast method to manage users (accsess to a page or dont accsee to a page) when they login?
You may want a simple solution but it's not a simple question.
At one end you could have individual permissions for each page for each user. That gives you a lot of flexibility but it would be an administrative nightmare. At the other end you could give users access or not to the whole site. Not very flexible but very easy to administer and code for.
The first is fine-grained. The second is coarse-grained. The whole point of finding an authorization scheme is to define one that is as fine or coarse grained as you need to balance flexibility and administration/development.
Two common schemes that may be of interest to you:
Give each user a type in the database. When they log in put that type (eg User, Admin, Moderator) in the session and check that on each relevant page;
Give each user one or more roles (so someone could, say, be both an Admin and a Moderator or just one of them or neither). This requires a separate table (users and userroles) and putting probably an array in the session to indicate roles but is more flexible than (1). Role-based authorization is very common.
There are many, many variations upon these two and just as many alternatives. Various schemes can be combined.
This is why generic authorization libraries for me fall short because they have contrary needs of being broad enough to cover a large number of use cases and being coarse-grained enough to be useful for the individual user.
Implement an ACL system.
A group of users form a role
A user may belong to many roles
Privileges are defined in the application - example, create user, post article. etc
Add privileges to roles via admin interface
Before the page loads, check ACL. If user belongs to a role with the required privileges for the requested page, allow user to continue. Else redirect to access denied page.
It can be easily achieved using third party libraries like Zend_Acl
Choose a library you are comfortable working with. But the basic idea remains same.
I am currently writing a CMS and remember someone (it might have been on here) criticise the existing CMS for not having a robust enough user permissions system. I've got a method planned out but it I feel it has fallen into the usual trap of being a bit too fine-grained which makes understanding and implementing it a horror for end users.
I think having a range of default user roles with permissions would be the answer to this, so I suppose my question is this:
What are the default roles you would like to see in a CMS and what sort of permissions would be associated with these?
Thanks in advance!
This is the "best practice" I have ended up with in most projects and am very happy with:
1. Roles
When it comes to roles, I recommend great flexibility, i.e. the ability to create and define user accounts and groups freely (roles like "contributor", "manager" etc. are not hard-coded, but put into a configuration file that can be changed per application). The role configuration is unaccessible to the user, but the engine itself should be free from hard-coded roles.
2. Rights
Rights is where things need to be easy to understand and implement.
I have made very good experiences working with, and checking against, very fine-grained rights on the code / API level:
see
view
edit
change name
rename
delete
move
change rights
etc.
but the user never sees those. For them, they are grouped into a very small number of "right groups":
Read Only
Edit
Administer = Move, rename....
The user never sees the "move" right, but only the "Administer" rights group.
That way, you retain the full power of fine-grained rights in your code for the future - you can, for example, easily accommodate for a rule like "interns must be able to edit pages, but not be able to change their titles, nor to delete them", adding a valuable asset to the CMS. For the end user, this functionality remains invisible, and the rights system easy to use.
I asked this question a little bit ago and got the following response.
admin //Manage everything
manager //Manage most aspects of the site
editor //Scheduling and managing content
author //Write important content
contributors //Authors with limited rights
moderator //Moderate user content
member //Special user access
subscriber //Paying Average Joe
user //Average Joe
Have you researched existing solutions like RBAC? Whilst such a system would most likely be complete overkill for the particular nut you're trying to crack it would at least help to boost confidence that you're on the right track.
That aside, the general roles I'd expect would be along the lines of:
Administator - Total control of the system, can view logs (as you should be logging all changes), etc. plus...
Publisher - Can put content live plus...
Author - Can create content
However, how these roles are applied across the system is where things get tricky, as a specific user would presumably have different rights to different content areas/modules.
For most applications, so I think it'll be true for CMSs as well, my customers usually prefer a rights-oriented approach. Here is how it goes :
You list the main actions. In your CMS that would be : Create and edit content; Delete content; Classify/categorize content; Validate content; Publish content; Manage users; Etc.
You define what actions are allowed or denied for each user
To make things a little better, you can create several roles (Editor; Administrator) to make typical users creation easier (by pre-filling the form when a role is chosen).
I have a custom CMS built on the Zend Framework that uses Zend's ACL to extends some basic roles (so you can deny resources specifically for additional users or allow others to access resources they normally couldn't). My basic roles go from CMS users all the way down to website "members" as follows (I just use one users table to store all my authentication).
Developer
Edit any content, edit layouts, settings, configuration. Use special tools that can call shell scripts and force cron jobs.
Admin
Edit any content, edit layouts, settings.
Author
Edit content.
Member
Can view the login screen, forgot password and bug report.
Now, Zend has a nice ACL implementation so you can easily extends your base ACL class and add new roles that extend from the basic roles. So I might make an "Admin" who has access to one of the Developer tools (e.g. purge or cache management) or lock an author to only be able to manage blogs (and not for example news).
I wouldn't necessarily dismiss the fine grained control system you have now. If you have one that is adaptable focus on hiding away the complexity by providing a simplified interface (eg use the facade pattern or the adapter pattern). The benefits are that you provide users with the simplified version (simple permissions like 'admin' can 'delete' a 'post') while still retaining the fine grained features should you need them later (eg more complicated permission handling is to allow to delete posts when the post is your own post in category X). Then you can provide an alternative to the simplified version for that need in some places.
Admin : The one with all the rights
Author : The one who has all rights to a specific content (like a blog author who owns the blog), also has the permissions to add/invite users to collaborate/view the content
Collaborator : The one who can edit/add content to which the author has given rights, cannot delete the content or invite/add more collaborators
Viewer : The one who can view the content if the author has invited to view
Editors : The one who can approve/edit all types of content
Having a fine grain control is not a bad idea if you expect advanced users/developers to use the CMS. But for novice CMS managers, the basic roles make the system much more usable.
Administrator - can create users + all below
Editor - can edit posts of others + all below
Author - can write posts, edit own posts
Creator - responsible for creating and editing content.
Editor - responsible for tuning the content message
and the style of delivery, including translation and
localization.
Publisher - responsible for releasing the content for
use.
Administrator - responsible for managing access
permissions to folders and files, usually accomplished
by assigning access rights to user groups or roles.
Consumer, viewer or guest- the person who reads or
otherwise takes in content after it is published or
shared.