Authorization « DerEuroMark

RSS

Posts Tagged ‘Authorization’

ACL – Access Control Lists – revised

06 Jan

With a focus on CakePHP application development.

Authentication vs Authorization

Those two are often confused. So here a little preface:

Authentication always comes first. It is about whether you are logged in or not. At this point it is not yet relevant who has access to what.
It is merely checked if the specific action/URL can be publicly accessed or needs authentication first.

After the authentication process, usually completed through some kind of login, the authorization decides on who can do what.
Here either roles or specific users are checked upon and the access is then either granted or denied.

Role Based Access Control (RBAC)

The easiest form of authorization is usually "role based access control", where you assign each other a role, and all that needs to be done is comparing
the user’s role (or roles in multi-role setups) to the required role for a specific action.
This can be realized with a single "roles" table and "role_id" in "users" table (or for multi-roles a "roles" and "user_roles" table) along with some table or file to store the
role/action relations.

Row Level Permissions

ACL is part of Authorization, the second step.
It is called "row level" access control, as it can go beyond just roles/actions combinations. Depending on the implementation it can also allow or deny specific users access to certain actions or records and make inheritable tree structures possible. So if you deny a certain user access to a node in the ACL tree(s), the sub-nodes are also prohibited by inheritance.
In its complex form (CRUD) it has even a flag for each type of action.
Such ACL trees can be quite complex to handle manually, and as such the tools provide you usually with some methods and CLI commands to make things easier.
So for the CakePHP core ACL there is even a plugin around some extra utilities for it.

ACO vs ARO

Read in the docs how ACL works regarding ACO (Access Control Object) / ARO (Access Request Object).
Essentially, ACLs are used to decide when an ARO can have access to an ACO.
While this post mainly focuses on controlling access to actions and records, ACOs could be anything you want to control, from a controller action, to a web service, to a line in your grandma’s online diary. So it allows you to make anything "accessible".

Why ACL?

First of all you have to assess what kind of authorization is needed for your application. In 95% of all cases, a full stack row level ACL is not even needed, and simple roles per user would suffice.

The main questions boil down to:
a) Does it need row level permissions as in "I need to allow/deny certain actions – or even specific records – to certain users"? Sure this can’t this be done with more roles?
If so, then go for some ACL implementation. If not (and this often times cuts down the complexity quite a bit) use a role based one.

b) Does it have to be dynamic? For row level this usually has to be some DB driven solution. For roles it is sure nice to have some backend, but in my experience
it is often not really necessary, at least if it is not some kind of CMS, but a web application that has developers close by.

So it results in 3 different outcomes:

Row level + dynamic (=ACL)
Role based + dynamic (=RBAC dyn)
Role based + static (=RBAC stat)

Note that the 2.x core ACL also provides an INI based approach, but that is not recommended and somewhat useless.

Problems with ACL

When working with ACL back in 1.x and 2.0/2.1/2.2 one large problem with it was speed.
It is both slow in generating the aco/aro tree from all actions available throughout the project as well as checking them.
Depending on the implementation this can sometimes be the bottleneck of some controllers and their actions.
Especially with a larger user base and a not so small app this can probably get out of hand very soon.

When building the aro/aco trees the resulting tree structure table always seemed quite fragile to me. At least a few times it got, for some reason,
broken, and repair tools had to recover the tree structure. It is also very difficult to debug due to its complexity.
Additionally, you have to be very carefully with handling the data: You cannot just delete a user manually, or reset/truncate a table. It always has to go through the ACL channels for the tree to stay valid and filled with the right data.

Another problem I encountered when working with ACL:
It is locked to the DB, instead of the code base. So reproducing some issues with accessing actions locally can become tedious as you have a totally different user-base, controlled records and thus ACL entries. And if you deploy, but forget to update the ACL (or some action is not added for some reason) people will be locked out without indication/feedback. If you upload new actions, the permissions to it will not always be deployed along with it which feels counter-intuitive to me.
That applies for any dynamic (DB driven) permission setup, of course. So role based ones with an admin backend wouldn’t be off the hook here.
Using static and "file commited" permissions here assert that those always fit to the current code base. I found that a lot easier to maintain and debug.

Static RBACs ftw

For the last 6 years I have never needed ACL for any of my applications or have it found useful for a lot of others I have examined.
Defining some good roles was enough. And it was simple. Additionally, by keeping it static I neutralized the issue with the "not-in-sync" issues above.

I see a lot of people over-engineering that part without the (immediate) need for it.
So I would really keep it as simple as possible until the use case for more complex mechanisms arises.

ACL definitely has its use cases, and I wouldn’t dare to call it evil, but it needs to be thoroughly thought through and not applied blindly.
In case you need to use it, check here, if the ActionsAuthorize (Uses the AclComponent to check for permissions on an action level) suffices over CrudAuthorize (action -> CRUD mappings).

Alternatives to the CakePHP core ACL

cakephp-annotation-control-list – a static mixture of role and record/row level permissions.

Alternatives on row level

Often times you can’t get around some basic row level checking, e.g. when a user may only edit/delete his own posts.

The book has examples on how to add the currently logged in user to the data upon add action, and how to check for edit/delete if that user is the owner of that record.
This can be done using the controller’s isAuthorized() method. A little bit of hardcoding saves a lot of trouble here.

Alternatives to ACL in general

Role based

TinyAuth – static INI files by default but could be easily made DB driven or at least backend adjustable.

Other

Controller based: ControllerAuthorize Calls isAuthorized() on the active controller, and uses the return of that to authorize a user. This is often the most simple way to authorize users. You can even mix role based with row level based auth if required.

Let me know if I forgot to list one. The full list of available plugins can be found at awesome-cakephp.

Last notes

In CakePHP3 ACL has been moved into a separate plugin, as it is just too much overhead for the core (since not so many actually use it) and doesn’t quite fit the 80%-rule therefore.

3 Comments

Posted in CakePHP

Auth – inline authorization the easy way

07 Apr

I wrote a wrapper class to make inline authorization easier.
Often times you want to check on certain roles inside an action or view and depending on the result display specific content or execute specific code.
As an example we only want to display the "admin infos" box on the home screen for an admin. All other users should not see this box.

Status quo

We would need to check the session manually against the roles we want to grant access to. This can get pretty hairy with more than one role allowed (if admins and moderators are allowed to see this box for example).

Preparations

We first need to make the class usable by putting this in our /Config/bootstrap.php:

// these IDs match the role_ids in the DB
define('ROLE_SUPERADMIN', '1');
define('ROLE_ADMIN', '2');
define('ROLE_MOD', '3');
define('ROLE_USER', '4');
// enable the Auth class
App::uses('Auth', 'Tools.Lib');

I like to use constants as they are shorter than Configure::read('admin') etc. But Configure would work just as fine.

Be aware: Since we already try to access the Tools plugin you need to assert first, that we enabled the Tools Plugin (using CakePlugin::loadAll() or a specific load call).

Then we need to decide whether we use single role (cake default) or multi role Authorization. I usually always use multi-roles. Therefore the default case for the Auth class is exactly this.
The session then contains:

Auth.User.Role (with Role being an array of role ids)

If you use single roles, you’re Session array should look like this:

Auth.User.role_id (with role_id being the single role we want to check against)

In this case you should set the following constant manually in your bootstrap:

define('USER_ROLE_KEY', 'role_id');

"Former" usage

For comparison I will outline the manual and "outdated" way of authorization first:

# we want to make sure that piece is only visible to admins and moderators
if ($this->Session->read('Auth.User.role_id') == ROLE_ADMIN || $this->Session->read('Auth.User.role_id') == ROLE_MOD) {}
# or with multi-role
if (in_array(ROLE_ADMIN, (array)$this->Session->read('Auth.User.Role')) || in_array(ROLE_MOD, (array)$this->Session->read('Auth.User.Role'))) {}

Quite a lot to write…

Note: This also only works in controller/component and view/helper scope. You would have to use the static CakeSession::read() in order to make this work in the model/behavior one etc.

Usage

Now the fun part. The wrapper class can be found in the Tools Plugin.

# Same thing as above
if (Auth::hasRoles(array(ROLE_ADMIN, ROLE_MOD)) {}

Now isn’t that nicer to write and read?

The default case is that if one of the roles is matched it will return true right away. If you want to connect them with AND instead of OR, you need to make the second param false:

# This only passed if the user has both roles!
if (Auth::hasRoles(array(ROLE_ADMIN, ROLE_MOD), false) {}

If we only want to check against a single role we could also use the shorthand:

if (Auth::hasRole(ROLE_MOD) {}

Advanced usage

You can also pass in the roles you want to check against. This can be useful if you want to check somebody else’s roles (and not your session roles). This can come in handy in CLI (command line / shell) environment and also in the admin backend.

if (Auth::hasRole(ROLE_MOD, $rolesOfThisUser) {}

And

if (Auth::hasRoles(array(ROLE_MOD, ROLE_USER), true, $rolesOfThisUser) {}

And there is more

There are also some convenience methods available.

Instead of $uid = $this->Session->read('Auth.User.id') you can just write

$uid = Auth::id(); // anywhere in your application

The roles can be fetched like this:

$myRoles = Auth::roles(); // string in single-role and array in multi-role context

Last but not least the user data:

$user = Auth::user(); // complete user array
$username = Auth::user('username'); // string: current username
...

Final notes

Although this wrapper can be used about anywhere in your application with ease does not mean one should do that.
Try to avoid using the auth (and therefore session) data in the model layer, for instance. Those should be kept state-less.
But I also know that there are cases where it is pretty convenient to ignore this warning 🙂

Disclaimer

Just for clarification: This class does not provide you with the Authentication or Authorization. This has to be up and running already. It is only a wrapper to check user roles a more efficient and cleaner way.

So if you need to setup a fresh authentication, you can just use the cake Form authenticate for example. If you want multi-role authorization you would want to throw in some additional spices:
You would need to write the Role array to your session upon successful login for the authorization module to work. See the above notes on how the session data array should look like.

For a new authorization take a look at my TinyAuth. It can handle single and multi role auth and those classes work well together (yeah – they have been designed to do that, of course^^).

No Comments

Posted in CakePHP

TinyAuth – The fastest and easiest authorization for CakePHP

18 Dec

Note: This is for CakePHP 2.x, for 3.x please see the bottom of the article.

The CakePHP built in row based CRUD auth is way too powerful and way too slow and memory consuming.
In 99% of all cases there is no need for that. Also, I never really used the groups + roles of the core ACL. Basic groups usually do the trick.

If you just want to have some basic control over the access to specific actions, you need something else.
Here it comes.

Demo (NEW)

A live implementation can be found in my fun app cakefest.
Note how lean and clean the User model and the controllers are. Separation of concerns. DRY. Cool 😛

Preparations

Please make sure the Tools Plugin is properly loaded (see the plugin readme for details).
If you plan on using prefixed routing (admin, …), enable those in your core.php or bootstrap.php.

I assume you already got the AuthComponent included in the $components array of your AppController.
You probably also excluded all public views with something like

$this->Auth->allow('contact_form'); // in beforeFilter() of the specific controllers

This here (in the contact controller) makes Auth skip this action completely. The action will be accessible to everybody right away.

This is especially important for your login/register actions:

// UsersController
public function beforeFilter() {
	parent::beforeFilter();
	$this->Auth->allow('login', 'logout', 'register', ...);
}

Those actions should never trigger any Authorize module. All other actions then use our ACL to determine if access is granted or not.

You probably got a Role model (User belongsTo Role / User hasAndBelongsToMany Role) attached to the User.
If you don’t want this, use Configure to store your keys like so:

// in your config.php if applicable or using Configure::write('Role', array(...))
$config['Role'] = array(
	// slug => identifier (unique magical number or maybe better a constant)
	'superadmin' => 1,
	'admin' => 2,
	'moderator' => 3,
	'helper' => 4,
	'user' => 5,
);

You should at least have a user – and maybe an admin role – for it to make sense.
The advantage here: At any time you can switch from Configure to a Role model + roles table and vice versa without having to change much.

You must also have some kind of Authentication in your AppController:

$this->Auth->authenticate = array('Form'); // Uses username and password for login

Important: At least one type of authentication is necessary for any Authorize module to be usable.

So far so good. You can login/logout and once you are logged in browse all non-public pages.
Even admin pages, of course. Thats where the TinyAuth class comes in.

TinyAuth

The code can be found at github.

First of all include it in your beforeFilter() method of the AppController:

$this->Auth->authorize = array('Tools.Tiny');

Alternatively, you could pass it as component settings right away:

public $components = [
        ...
        'Auth' => [
            'loginRedirect' => ...,
            'logoutRedirect' => ...,
            'authenticate' => ['Form'],
            'authorize' => ['Tools.Tiny']            
        ],
];

Now create a file in /Config/ called acl.ini like so:

[Tools.Countries]
* = superadmin ; this is a comment
[Account]
edit,change_pw = *
[Activities]
admin_index,admin_edit,admin_add,admin_delete = admin,superadmin
index = *
[Users]
index,search = user
* = moderator,admin

The format is normal PHP INI style. I already included all kind of examples. * is a placeholder for "any".
The plugin prefix for controllers is not necessary as of now (maybe for CakePHP 3 where the same controller name is allowed multiple times due to PHP5.3 namespaces).
Comments in INI files start with ";".

Explanations:

Superadmin can access all Countries actions of the Tools plugin
Account actions are accessible by all roles (and therefore logged in persons)
Activities can be modified by all admins and listed by all (logged in persons)
Users can search and list other users, but only moderators and admins have access to all other actions

That’s it. Really easy, isn’t it?

Some details

TinyAuth expects a Session Auth User like so:

Auth.User.id
Auth.User.role_id (belongsTo - role key directly in the users table)

or so:

Auth.User.id
Auth.User.Role (hasAndBelongsToMany - multi role array containing all role keys)

As you can see it can manage both single and multiple role setup.
That’s something the core one lacks, as well.

The current configuration is cached in the persistent folder by default. In development mode (debug > 0) it will be regenerated all the time, though. So remember that you have to manually clear your cache in productive mode for changes to take effect!

For more insight into the different role setups see this Wiki page.

Quicktips

If you have a cleanly separated user/admin interface there is a way to allow all user actions to users right away;

$this->Auth->authorize = array('Tools.Tiny' => array('allowUser' => true));

Only for admin views the authorization is required then.

If you got a "superadmin" role and want it to access everything automatically, do this in the beforeFilter method of your AppController:

$userRoles = $this->Session->read('Auth.User.Role');
if ($userRoles && in_array(Configure::read('Role.superadmin'), $userRoles)) {
	// Skip auth for this user entirely
	$this->Auth->allow('*'); // cake2.x: `$this->Auth->allow();` without any argument!
}

What about login/register when already logged in

That is something most are neither aware of, nor does the core offer a out-of-the-box solution.
Fact is, once you are logged in it is total nonsense to have access again to login/register/lost_pwd actions.
Here comes my little trick:

// In your beforeFilter() method of the AppController for example (after Auth adapter config!)
$allowed = array('Users' => array('login', 'lost_password', 'register'));
if (!$this->Session->check('Auth.User.id')) {
	return;
}
foreach ($allowed as $controller => $actions) {
	if ($this->name === $controller && in_array($this->request->action, $actions)) {
		// Flash message - you can use your own method here - or CakePHP's setFlash() - as well
		$this->Common->flashMessage('The page you tried to access is not relevant if you are already logged in. Redirected to main page.', 'info');
		return $this->redirect($this->Auth->loginRedirect);
	}
}

It is also visible in the linked CakeFest app demo.

UPDATE 2012-01-10

The auth model can now be anything you like. It doesn’t have to be Role or role_id.
The new CakePHP 2.x uses "groups" per default.
You can easily adjust that now by passing aclModel => 'Group' or aclKey => 'group_id' to the Tiny class, for instance.

UPDATE 2013-03-10

Some will be happy to hear that the deeper "contained" Role array is now supported besides the flat array of role keys. This deep/verbose array of roles has been introduced in CakePHP 2.2 with the new "contain" param for Auth. So it made sense to support this in TinyAuth. See the test case for details.

UPDATE 2013-06-25

A new option allowAdmin makes it now possible to use TinyAuth even with less configuration in some cases. True makes the admin role access any admin prefixed action and together with allowUser (allows all logged in users to allow non admin prefixed URLs) this can be used to set up a basic admin auth. No additional configuration required except for the adminRole config value which needs to be set to the corresponding integer value.
Of, course, you can additionally allow further actions. But if you just need to quickly enable an admin backend, this could be the way to go.

Notes

NOTE 2012-02-25

It seems that especially new-beys seem to mix up the meaning of * in the ACL. Although it is already laid out in the above text I will try to make it more clear:
This any placeholder for "roles" only refers to those users that are logged in. You must not declare your public actions this way!
All those must be declared in your controller using $this->Auth->allow() (in earlier versions of CakePHP `$this->Auth->allow(‘*’)).

The reason is that Authenticate comes before Authorize. So without Authentication (logged in) there will never be any Authorization (check on roles).

NOTE 2013-02-12

You can use this in conjunction with my Auth class for a quick way to check on the current user and its role(s) anywhere in your application:

App::uses('Auth', 'Tools.Lib'); // In your bootstrap (after plugin is loaded)
if (Auth::id()) {
	$username = Auth::user('username');
	// do sth
}
if (Auth::hasRole(Configure::read('moderator'))) { // if you used configure slugs
	// do sth
}
if (Auth::hasRoles(array(ROLE_ADMIN, ROLE_MODERATOR)) { // if you used configure and constants instead of magic numbers
	// do sth
}

See the inline class documentation or the test cases for details.

Upcoming

A shell to quickly modify the INI file (and batch-update for new controllers etc) should be ready some time soon.

There might some day also the possibility to use some CRUD backend to manage the ACL (either via database or modifying the INI file).
If someone wants to help, go for it.

2014-09: CakePHP 3.0

With the release of CakePHP 3.0 I upgraded the TinyAuth code and moved it into an own repository.
Please see the wiki page there for docs and migration guide.

64 Comments

Posted in CakePHP

CakePHP Sandbox
- Try it out now!
Search the site
Search
Support this site
Tags
Access ACL Auth Authentication Authorization Bake Behavior Bootstrap CakePHP CakePHP1.3 CakePHP2 CakePHP3 Coding Standards Component Composer Console Custom Template Database date Debian Git Helper HTML5 IDE Lib Migration Model Passwords PHP PHP5 PHP5.4 PHPUnit Placeholder Plugin redirect Security Subversion SVN Testing Tips Unit-Tests Upgrade Validation XHTML XSS
Categories
- Common (6)
- VersionControl (7)
  - Git (2)
  - SVN (5)
- WebDevelopment (138)
  - HTML (2)
  - JS (2)
    - jQuery (2)
  - MySQL (1)
  - PHP (131)
    - CakePHP (116)
  - Testing (5)
Recent Posts
Recent Comments
- Tomas Votruba on CakePHP 3.6 is coming
- Mark on How to implement Captchas properly
- Siddharth on How to implement Captchas properly
- Christian on Helper? Component? Lib? CakePHP2
- Gio on ACL – Access Control Lists – revised
Calendar
October 2018

M T W T F S S

« Jul

1 2 3 4 5 6 7

8 9 10 11 12 13 14

15 16 17 18 19 20 21

22 23 24 25 26 27 28

29 30 31
Archives
Archives
Pages
Popular Posts
Bookmark this
Facebook Google+ Twitter Pinterest

Delicious Digg Fark Google Instapaper LinkedIn MySpace Newsvine Pocket Readability Reddit StumbleUpon Tumblr Yahoo!

October 2018
M	T	W	T	F	S	S
« Jul
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

DerEuroMark

Posts Tagged ‘Authorization’

ACL – Access Control Lists – revised

Authentication vs Authorization

Role Based Access Control (RBAC)

Row Level Permissions

ACO vs ARO

Why ACL?

Problems with ACL

Static RBACs ftw

Alternatives to the CakePHP core ACL

Alternatives on row level

Alternatives to ACL in general

Role based

Other

Last notes

Auth – inline authorization the easy way

Status quo

Preparations

"Former" usage

Usage

Advanced usage

And there is more

Final notes

Disclaimer

TinyAuth – The fastest and easiest authorization for CakePHP

Demo (NEW)

Preparations

TinyAuth

Some details

Quicktips

What about login/register when already logged in

UPDATE 2012-01-10

UPDATE 2013-03-10

UPDATE 2013-06-25

Notes

NOTE 2012-02-25

NOTE 2013-02-12

Upcoming

2014-09: CakePHP 3.0

CakePHP Sandbox

Search the site

Support this site

Tags

Categories

Recent Posts

Recent Comments

Calendar

Archives

Pages

Popular Posts

Bookmark this