Permissions System of a relatively complix webApplication

i'm asking about a way to set up permissions system.开发者_如何学Go The applications consists of Organizations of different level of visibility , sub- entities, topics, plans and many others. The permissions of a user depend on his role in a certain Organization as well as the entity it self (eg a user may be allowed to view a certain plan and be blocked from viewing another plan even if both belong to the same Organization). A user may be assigned to a wide range of roles -the roles will differ according to the Organization- and a user may be enrolled in different Organizations .There are many actions that need permissions.

so any suggestions?! , Thanks in advance

The Open Web Application Security Project (OWASP) is a 501c3 not-for-profit worldwide charitable organization focused on improving the security of application software. Our mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license.

OWASP is where you need to be;

• Identify user roles and resource capabilities
• Document security-relevant requirements
• Identify resources and trust boundaries
• Research and assess security posture of technology solutions

I'm not quite sure if you're asking how to design this, or how to implement it.

In terms of design, this sounds like it could be solved with a model such as the good old UNIX permissions system or access control lists. Either way, you will need know:

• What permissions a user has
• What permissions are required to perform some operation on some resource

So your user and resource objects will need to be able to carry those. Then it's just a matter of, wherever something sensitive is done, finding who is doing it, and checking that they have the appropriate permissions.

Some things to note:

• There will be a lot of permissions; potentially one (or several) per resource. The UNIX groups model helps here, because you can mark a resource as being "writable by anyone in group X", and then just add people to group X
• One of the operations on resources will be altering the permissions of a user, so users are also resources.