Everything in Symfony2 looks pretty good however there is one issue I can't seem to find a solution too. The issue is that Symfony2's security component is limited to 30-32 roles/permissions. One of my projects, a project management/issue tracker system, is going to need more than 32 permissions. There are a number of different components of the system that need to have there own set of permissions. Just because someone has create, read, update, or delete permissions to issues does not mean they have those permissions for projects, milestones, etc... Each component is going to need its own create, read, update, and delete permission not to mention component specific permissions and there is no doubt I will reach the 30-32 roles/permission limit.
I have questioned in IRC and the mailing list with no really direction of where to go. I would prefer to be able to just added this functionality on top of the existing security component (preferably through a bundle). I am not sure how I can achieve more than 30-32 roles/permissions with symfony2's security component.
I would really prefer not to have to development my own security system w/ ACL.
as stated before in the question comments by gilden:
But this is exactly the use case for ACL. You can start using the built-in ACL system today! It's quite easy to modify/extend as well to best suit your needs.
For beginners, I think it's best to read these articles from Symfony2 official book in the following order:
Security - Including info about: Authentication and Authorization, Users & Roles, Access Control in Templates & Controllers
Access Control Lists (ACLs) - Including info about: Bootstrapping & configuration, Creating an ACL, an ACE, Checking Access & Cumulative Permissions
Advanced ACL Concepts - Including info about: Design Concepts, Database Table Structure, Scope, Pre- & Post-Authorization Decisions, Process for Reaching Authorization Decisions
There are also some interesting question here at SO.com about Symfony2 ACLs
Good luck!
I think you kind of misunderstood the acl system you can only create 32 kind of role, but by domain object. This is done using bitmasks operations on integers ( this explaining the '32' limitation as an integer is ... well you know the answer ).
So for example the permission to delete one object would be same - 'MASK_DELETE' - for a project a milestone or a ticket. So if you used the ProblematicAclManagerBundle you would just have to do :
$aclManager->addPermission($ticket, $userEntity, MaskBuilder::MASK_DELETE);
or
$aclManager->addPermission($projet, $userEntity, MaskBuilder::MASK_DELETE);
to give your user permission to delete $project or $ticket for instance. It also creates the acl entry for the domain object and the entry for the user if they are not already there. What I need to know though is if you can create different masks names for a class, or every class of a bundle ?
You will find a deeper explaination on acls here
I know this is an old post, but I just wanted to share this with anyone who has a similar answer.
The key to providing a solution is in this sentence in your question:
There are a number of different components of the system that need to have there own set of permissions.
For each of these components you could create a separate voter.
Create a class that extends AclVoter.
Override the supportsClass() method to make sure the voter will only vote for classes of the component it is meant for.
Create your own PermissionMap containing the set of permissions the component needs.
Pass the PermissionMap to the AclVoter in your services configuration.
Tag the voter as security.voter so the AccessDecisionManager will start using it.
This should get you a long way.
I also recommend going thought the code of the ACL Component, there are a lot of features that unfortunately aren't documented.
Related
Fluid looks really nice if all collaborators are equal (allowed to change the same resources), but what I don't understand is how the server can prevent certain actions for certain users. As much of the logic as possible is on the client-side right? Maybe I haven't searched good enough, but I couldn't find a resource or readme that explained that part.
Example:
User A can edit the whole markdown document.
User B can edit the whole markdown document.
Both users can lock paragraphs they've created to be read-only, which only they can unlock again.
On the Fluid FAQ it states the following:
Turn-based games?
DDSes can be used to distribute state for games, including whose turn it is. It’s up to the client to enforce the rules of a game so there may be some interesting problems to solve around preventing cheating but the Fluid team has already prototyped several games.
If there is no solution for this problem, please let me know where I should start would I fix this myself. For a fun hobby project, I'm in the middle of deciding to build something new or to use fluid (which can save me a lot of work).
Right now, Fluid doesn't have the concept of Access Control, but we could include some related features as DDS features, we could implement some features as server-hosted Fluid Bot filters, and we could implement basic ACLs at the server layer as Storage ACLs.
As DDS Features
I wrote the "OwnedMap DDS" to show this concept, where users reject invalid changes from other users. This could be extended to include your "paragraph lock" concept, but I'm not sure it's rigorously secure.
I think it'd be interesting to build a library of "OwnedDDS" or DDS with filter methods on them to prevent invalid changes".
server-hosted Fluid Bot filters
Another option is to have a server side client, so a non-user client that joins the session that is not a malicious actor. This Bot could validate that changes are legitimate and then "consent" to the changes. This breaks some optimistic insert constraints, but would add more security and is more rigorously secure.
With this approach, you may still need to modify DDSs so that they're consensus based instead of optimistic, but the only consensus would be that the Bot agrees the change is valid.
Storage & Server level ACLs
You could imagine modifications to the routerlicious reference service where you need a user login to access specific containers. This is not as find grained as your request, but would clearly work!
How I can implement ABAC in nodejs. I want to give access to user using his location and role.
any one have demo for it?
I am refering npm package PolicyLine: npm i policyline refer link - https://www.npmjs.com/package/policyline
Even though this question is a bit old, I still want to give some answer for other users, which have the same or similar question in mind.
To answer your initial question:
It depends on your requirements and application. If you need to hide or show some fields based on permissions and roles, you should go with ABAC. If you just want to do permissions based on models/entities then a simple ACL would work or even just some predefined roles in a simple domain.
So usually you know what you need. Depending on the application one solution (or library) can be totally fine/overkill and in another it is just enough.
BTW:
I also can recommend https://casl.js.org/ which is actively maintained and also offers ABAC (including time based permission checks).
I'm working on my first "real" DDD application.
Currently my client does not have access to my domain layer and requests changes to the domain by issuing commands.
I then have a separate (flattened) read model for displaying information (like simple CQRS).
I'm now working on configuration, or specifically, settings that the user configures. Using a blog application as an example, the settings might be the blog title or logo.
I've developed a generic configuration builder that builds a strongly typed configuration object (e.g. BlogSettings) based on a simple key value pair collection. I'm stuck on whether these configuration objects are part of my domain. I need access to them from the client and server.
I'm considering creating a "Shared" library that contains these configuration objects. Is this the correct approach?
Finally where should the code to save such configuration settings live? An easy solution would be to put this code in my Domain.Persistence project, but then, if they are not part of the domain, should they really be there?
Thanks,
Ben
User configurable settings belong to domain if they are strongly typed and modeled based on ubiquitous language, i.e. 'BlogSettings'. The only difference between settings and other domain objects is that conceptually settings are 'domain singletons'. They don't have a life cycle like other Entities and you can only have one instance.
Generic configuration builder belongs to Persistence just like the code that is responsible for saving and reading settings.
Having found this question, I feel obliged to suggest an answer because I don't like the accepted one.
First off I don't see why this has to be a singleton.
Secondly, there is something about settings that is very important: they are usually hierarchical, and they almost always have to have the concept of defaults. Sometimes those defaults are at the item level. Other times you might prefer to replicate a whole set of defaults. Also, consider the fact that settings can use the concept of inheritance: maybe an agency has a setting, but it permits agents the ability to do their own.
I am researching security frameworks for an ASP.NET MVC3 application that would have some pretty complex authorization rules in terms who can see data, who can create and edit it. Rules such as
- I can only see clients that are part of my company or branch.
- If I am out 15 or less days from the day the record was created and my role is of super user then only I can edit all but two fields on that record. After 16 days or more I can only edit two fields.
My initial thought was to use the Enterprise Security Block and just add customized authorizers, but after reading more about the native support for membership based security in ASP.NET, I am not so sure if Enterprise Security Block is necessary. I have not use neither of the frameworks in a real-world application so looking for some collective wisdom on the topic.
This is the problem with complex field level security. There is no real framework to help you with it, because everything is so custom. The best you can do is extract this into some kind of lookup table, and assign each field a custom identifier in the table, then have a set of columns that indicate each security level. Then, you build your business logic so that you pass in a field and conditions, and it simply responds back whether or not to allow it.
THen you have to figure out what "allow" means in your interface. Disable it? Hide it? ignore it?
I don't envy you.
You might find this semi-interesting.
http://bartreyserhove.blogspot.com/2008/12/field-level-security-using-aspnet-mvc.html
You can use Azman - Microsoft Authorization Manager and its related APIs.
It provides you with roles, actions, permissions and many more configurable options.
Azman uses AD to store most of this. It also provides options to store using local XML and/or configuration files.
You are crossing into more than just direct security concerns here but actually authorization rules AND edit rules. Your auth rules sound quite custom and I feel that you may need to process these rules in your own custom code and then include these Attributes in your own view models.
Im not aware of any frameworks that will give you this by default as these are very custom editing rules. You could call these claims and when you login go against a claims based framework such as windows identity foundations (WIF) but you will still need custom IF stmts to allow editing in your view based on properties you set in your ViewModel such as CustomerViewModel.AllowAddressEdit. Your view needs to then check this property to display DisplayFor or EditorFor. However you should also check these values on postback to ensure a user hasn't just injected values to hack your app.
You can use asp.net security for basic authentication to the site, and you can use it for basic role membership. But since these are site-wide permissions, you will need your own logic to segment users into organizational permissions.
What I've done in the past is use the asp.net membership logic to handle the basic auth stuff, but then keep another structure in your database that maps the user id's to other parameters - like the mentioned organizational level membership, or especially access rights for data-driven structures.
I'm actually surprised there aren't better solutions already built out there for handling more complext membership/permissions situations that many apps need.
I am pretty much confused as to when I should implement an ACL (access control list) system in my application though I can easily manage permissions on groups simply by fetching the session group id and restricting the access using the Auth component.
How is an ACL solution better then the approach I discussed above (restricting the group access based on group id) ?
How does implementing an ACL solution simplify things when it comes to managing access rights in your application ?
Till now I have learned that through ACL, permissions can be granted and revoked at runtime, but this functionality is also achievable without using an ACL.
I am very much confused about this, please help me understand the concept, when to use ACL and the benefits of using ACL in your web application.
I prefer to code with cakePHP v1.3 so it would be great if the explanation is given in context of cakephp but any help (language/technology independent) related to my question is greatly appreciated.
You must use ACLs (or an equivalent user permission mechanism such as literal database User and Permission tables) rather than groups if you need to control access to individual entities which vary dynamically. File systems attach ACL's to individual files since you don't want to create a separate group for each file. Database managers attach ACL's to databases, tables, views, stored procedures and whatnot for the same reason. Web servers deal with web applications in the same manner.
In a business application dealing with business entities, you may want to partition access to entities such as e.g. different sales orders, customers, products or divisions within your company, where not everybody is allowed to create/update or even read the same entities. For instance, when sales staff are in direct competition for bonuses, they don't want everybody else to see all the information on their CRM-stored prospects.
Usually, though, you want to keep your access mechanisms as coarse-grained as is humanly possible: groups are usually good enough. Fine-grained access control mechanisms have a tendency to grow complex, expensive, inaccurate and hard to use correctly. They may even decrease security, since administrative frustration encourages people to find clever workarounds...
I think that ACL technic for securising user access to ressources is usefull only for a typical or medium - sized application . for big applications like CRM or financial data warehouses , ACLs will fail to manage a very complex set of user / ressource couples , when the data increase in size , in type and in volume , the ACLs tables made for that purpose will increase too , which it make for me no sense to overload the database server with ACL Tables. There are many others technics used to install security access and permissions and privileges ... The use of ACL files instead does not sound bad but it is not a good idea as files may corrupt from time to time so data failure is over the risk to not have access to a file containing ACL rules or to access a non existing file or a lost one ... The only way to play with permission is to use the business tables used in the context or in the purpose of your application with relationships between your tables and some logic to add to your Service Side Scripts if you are under MVC Architecture or any else ... So Avoid using ACL for very big sized applications.