I’m involved in the development of a large web application (using Zend Framework) with many different types of entities inside! Some functions performed on these entities should be accessible to some users but not others… To make things more interesting users can assign other users with rights to these entities…

We’re going for a hands off user administration model where users register themselves, create things themselves, and give other users access to them.. THEMSELVES!

This article is Part 1 of many as I design and create a Zend Controller Plugin designed in simple terms to check if the user is allow to do whatever the hell they’re trying to do… I’d like to reuse it forever and a day though, so we need more functionality and flexibility…. My list of requirements goes on:

• Simplified everything - Can we use 1 line to kick off all ACL checks?
  No one likes having to include the ACL checking at the top of everything, and worse yet implicitly define what it is the page does, or who should access it… So we’ll require none of this!!
• Anonymous users should not be discriminated against!
  Anonymous users should be treated just like any other authenticated user - their access should be checked using the same process, and stored in the same manner! Examples of benefits:
  • Simplifies management the ‘anonymous user’ by using a normal role.
  • Logging (e.g. Ann performed this action) and metadata (e.g. updated by Ann) functions don’t need to cater for the irregularity of an ‘unknown’ user.
  • Explicit access to entities can checked/stored in the same way as normal users. For example - I want to make my Social networking profile publically viewable.

• Users should have generic roles!
  This means even though some users may not have implicit access to some entities, they can still have access! This is a more typically found smaller applications so definitely needs to be included.. Some example usage scenarios are:
  • Administrators - Access to everything!
  • Support staff - Application support staff may need to see ’stuff’; manage user accounts.
  • Moderators/Editors - Can approve anything/Can edit anything.
  • Anonymous - Allowed to see log in page.

• Users might have explicit privileges to supercede generic ones!
  This provides a way for use to either grant or restrict access to specific entities regardless of the users generic role. An example scenarios:
  • “Support staff” should b restricted from managing Administer accounts.
  • A user by default can’t edit ‘comments’, but can edit their own.

• Actions can depend on actions too!
  If a user has permission to perform a certain action, there may be other actions they should also have access to automatically. Example scenarios:
  • The ‘Register user’ action uses another action for AJAX validatio
  • The ‘Latest news’ action has an equivalent RSS/ATOM feed through another action

• Required ID checking for actions (soo not typically in scope, I know!)
  I need to explore this idea a little further (I’m not sure it will make the cut yet)… This typically wouldn’t be included in scope for a access control class! BUT… In this ACL model we’ll allow for checking if a user has access an perform an action on a specific entity. And we need to know the entity’s ID and what the entity is right?… So it seems only logically to store what actions REQUIRE what types of entity ID’s… Maybe we’ll go so far as to check they exist?

Assumptions

I’ll never have access requirements more specific than the action being requested!

Basically my ACL will define a users permission (ie. can access OR can’t access) to a specific action and its relationship with an entity if applicable. It will not be able to say a user can only partially see/run the action.

This will likely however still be achievable within this application itself. But it’s definitely outside of the scope of this particular Controller Plugin.

By ‘action’ I mean the standard route in Zend Framework (ie. Module/Controller/Action). So we’ll assume I’ll always be using it…

End note

Obviously every project always has unique requirements so I don’t anticipate what I’m working on will suit EVERYONE… But considering I’m designing this for maximum reused I would very much appreciate hearing the many weird and unique access control requirements you’ve encountered.

While I’m working on it I would like to incorporate the anything that is realistically reusable…