Planet CakePHP

Access Control Lists, or ACLs, provide a good level of access control on any site. Code bases and platforms may use a different method of instituting ACLs and I am going to go through how CakePHP 1.2.x is handling them.
First is to understand what an ACL really is. The Cookbook has a good page explaining this type of concept. I highly recommend reading through this page. The whole concept behind this ACL can be divided in three parts:

• ACO – Access Control Object, object that is being requested
• ARO – Access Request Object, object that is putting in the request
• ACL – Access Control List, determines if an ARO can access an ACO.

In the Cookbook, they have a very good call out about the ACL, it is not authentication. No matter what code base, or platform you are on, never mistake this. The ACL verification only happens after the person logs in. They can be very powerful together, but authentication must happen first.
The next thing to understand is the way an ACL would look in a matrix. Again, the Cookbook provides a great example of this. The one thing that I would rather prefer, but understand why they do this, is the use of the example. Sure, we all like movies, and the Lord of the Rings is a great way to really explain different things, but it may be hard to switch that over to the real world of coding. So for this entry, I am going to use as an example, and Event Calendar.

In this Event Calendar, here is the breakdown: there are events, there are groups, there are users. Each user is going to be a member of a group. A group will have a “leader” who can add, edit or delete group events. A group will also have an “editor” who will be able to add or edit group events. And the default group membership is one who can only view group events.

• Groups
• – Leader
• – - Add, edit, delete group events
• – - View all group events
• – Editor
• – - Add, or edit group events
• – - View all group events
• – Member
• – - View all group events

Users will be anyone who creates a login to the application. Of course there will be a “site admin” who can add, edit, delete to any user account except their own. They can assign a user to a group, or remove memberships. The group leader can add or remove memberships to their own group only. They can not add, edit or delete user accounts. The default user can edit their own account, and request for the account to be deleted (they can not delete their own account).

• Users
• – Site Admin
• – - Add, edit, delete all user accounts (except the site admin account)
• – - Add, or remove users from any group
• – Leader
• – - Add or remove users from their own group only
• – Users
• – Sign up for an account, edit only their profile
• – request to be a member of a group

Events can be either a group event, or an individual event. Group members can see group events, and an individual event is only available to be viewed by the user who entered the event.

• Events
• – Group Events
• – - Viewable by members of the group
• – Individual Events
• – - Viewable only by the user who entered the event

To put this in a “use case” scenario, here are four examples:
Case 1: Username “MotoCrash” is a registered user of the site. He is also a group leader of the “ProFootball” group. He is able to update membership of the group, and is able to edit the different events for the group calendar. There are some events he has had to delete. He often updates his own account with a new avatar image. He can view all of the group events to determine if any of them need to be edited.
ARO = “MotoCrash”
ACOs = Groups, Events, Users
Case 2: Username “FootballNut” is a registered user of the site. He is a member of two (2) groups. He is a regular member of the group named “ProFootball” and a group leader of “PopWarnerBall”. He is able to see events in both groups, but is only able to add, edit, or delete events in the “PopWarnerBall” group. He adds his own events for personal uses that only he is able to see.
ARO = “FootballNut”
ACOs = Groups (2 checks), Events
Case 3: Username “Angel” is a regular member. She is not part of a group as of yet, but posts events to her own personal calendar. She is able to edit her account, adding a new signature line every month. She is able to view her own events. She is an avid football fan, but is unable to see events for the ProFootball group.
ARO = “Angel”
ACOs = Groups, Users, Events
Case 4: Username “Admin” is a the site admin. They are able to do all actions in any group, and able to update any memberships, or add, edit or delete accounts. They are not able to delete their own account.
ARO = “Admin”
ACOs = Groups, Events, Users, Administation

 
Users

Area
MotoCrash
FootballNut
Angel
Admin

Group ACO: ProFootball
 

Add Members
X
-
-
X

Remove Members
X
-
-
X

Group ACO: PopWarnerBall
 

Add Members
-
X
-
X

Remove Members
-
X
-
X

Event ACO: ProFootball
 

View Events
X
X
-
X

Add, Edit or Delete Events
X
-
-
X

Event ACO: PopWarnerBall
 

View Events
-
X
-
X

Add, Edit or Delete Events
-
X
-
X

Individual Event ACO: MotoCrash
 

View, Add, Edit, Delete Events
X
-
-
X

Individual Event ACO: FootballNut
 

View, Add, Edit, Delete Events
-
X
-
X

Individual Event ACO: Angel
 

View, Add, Edit, Delete Events
-
-
X
X

User ACO
 

Update Own Account
X
X
X
X

Update Other Account
-
-
-
X

Delete Own Account
-
-
-
-

Delete Other Account
-
-
-
X

I hope this has been helping to better understand ACLs. In order to really delve into this topic, and separate the different areas, I am finishing this post here. I am going to post another one that gets into the code of setting up the tables (acos, aros, aros_acos), and then the coding portion of the ACLs, like when a new user is created, group membership changes, or how to validate on the ACL based on the logged in user.