rich97 / li3_access

Li3 Access Library

#Access control library for the Lithium framework.

##Installation

Checkout the code to either of your library directories:

cd libraries
git clone https://github.com/rich97/li3_access.git

Include the library in in your /app/config/bootstrap/libraries.php

Libraries::add('li3_access');

##Usage

You must configure the adapter you wish to use first, but once you have it configured it's fairly simple to use.

$access = Access::check('access_config_name', $this->request, Auth::check('auth_config_name'));
if(!empty($access)) {
	$this->redirect($access['redirect']);
}

If the request validates correctly based on your configuration then Access::check() will return an empty array() otherwise it will return and array with two keys; message and redirect. These values are built into the Access class but you can override them but passing them as $options to all three of the adapters in this repository.

##Configuration

In this repository there are three adapters. All three work in a slightly different way.

###Simple Adapter

The simple adapter is exactly what it says it is. The check method only checks that the data passed to is not empty and as a result the configuration is trivial.

Access::config(
	'simple' => array('adapter' => 'Simple')
);

And that's it!

###Rules Adapter

This adapter effectively allows you to tell it how it should work. It comes with a few preconfigured rules by default but it's very simple to add your own. Its configuration is the same as the Simple adapter if you only want to use the built in methods.

Access::config(
	'rules' => array('adapter' => 'Rules')
);

Then to deny all requests from the authenticated user.

$access = Access::check('rules', Auth::check('auth_config_name'), $this->request, array('rule' => 'denyAll'));
if(!empty($access)) {
	$this->redirect($access['redirect']);
}

There are four built in rules; allowAll, denyAll, allowAnyUser and allowIp, for more information see the adapter itself. However, this adapter is at it's most useful when you add your own rules.

Access::adapter('custom_rule')->add(function($user, $request, $options) {
	// Your logic here. Just make sure it returns an array.
});

Then to use your new rule:

$access = Access::check('rules', Auth::check('auth_config_name'), $this->request, array('rule' => 'custom_rule'));

One more to go!

###AuthRbac Adapter

This is the most complex adapter in this repository at this time. It's used for Role Based Access Control. You define a set of roles (or conditions) to match the request against, if the request matches your conditions the adapter then checks to see if the user is authenticated with the appropriate \lithium\security\Auth configurations to be granted access.

It's difficult to explain (I hope that's clear enough) so lets look at an example configuration to try and achive some clarity:

$accountsEmpty = Accounts::count();

Access::config(array(
	'auth_rbac' => array(
		'adapter' => 'AuthRbac',
		'roles' => array(
			array(
				'resources' => '*',
				'match' => '*::*'
			),
			array(
				'message' => 'No panel for you!',
				'redirect' => array('library' => 'admin', 'Users::login'),
				'resources' => 'admin',
				'match' => array('library' => 'admin', '*::*')
			),
			array(
				'resources' => '*',
				'match' => array(
					'library' => 'admin', 'Users::login',
					function($request, &$options) {
						return !empty($request->data);
					}
				),
				'allow' => function($request, &$options) use ($accountsEmpty) {
					if ($accountsEmpty) {
						$options['message'] = 'No accounts exist yet!';
					}
					return $accountsEmpty;
				}
			),
			array(
				'resources' => '*',
				'match' => array('library' => 'admin', 'Users::logout')
			)
		)
	)
));

First we tell it which adapter to use:

'adapter' => 'AuthRbac',

Then we set the roles array. This array is required if you want to use this adapter. The roles are evaluated from top to bottom. So if a role at the bottom contradicts one closer to the top, the bottom will take precedence.

####There are five possible options you can specify for a single role.

'message'

Overwrites the default message to display if the rule matches the request and is disallowed.

'redirect'

Overwrites the default redirect to use if the rule matches the request and is dissallowed.

'match'

A rule used to match this role against the request object passed from the check() method. You may use a parameters array where you explicitly set the parameter/value pairs, a shorthand syntax very similar to the one you use when generating urls or even a closure. Without match being set the role will always deny access.

In the closure example configuration:

'match' => array(
	'library' => 'admin', 'Users::login',
	function($request, &$roleOptions) {
		return !empty($request->data);
	}
)

Not only must the library, controller and action match but the closure must return true. So this role will only apply to this request if all of the request params match and the request data is set.

'resources'

A string or an array of auth configuration keys that this rule applies to. The string * denotes everyone, even those who are not authenticated. A string of admin will validate anyone who can be authenticated against the user defined admin Auth configuration. An array of configuration keys does the same but you can apply it to multiple Auth configurations in one go.

Assuming we have an Auth configuration like so:

Auth::config(array(
	'user' => array(
		'adapter' => 'Form',
		'model' => 'User',
		'fields' => array('email' => 'email', 'password' => 'password'),
		'scope' => array('active' => true)
	),
	'editor' => array(
		'adapter' => 'Form',
		'model' => 'Editor',
		'fields' => array('email' => 'email', 'password' => 'password'),
		'scope' => array('active' => true, 'group' => 1)
	),
	'customer' => array(
		'adapter' => 'Form',
		'model' => 'Customer',
		'fields' => array('email' => 'email', 'password' => 'password'),
		'scope' => array('active' => true, 'group' => 2)
	)
));

Setting 'resources' => array('user', 'customer') would only apply the rule to anyone that could authenticate as a user or customer. Setting 'resource' => '*' would mean that all of these auth configurations and people that are not authenticated would have this role applied to them.

'allow'

A boolean that if set to false forces a role that would have been granted access to deny access. Much like the 'match' option you can also pass a closure to this option. This way you can blacklist every resource and then whitelist resources manually. Also by passing a closure you can deny access based upon the request.

Finally, if you pass either $request or $options you can modify their values at runtime.

###Filters

The Access::check() method is filterable. You can apply the filters in the configuration like so:

Access::config(array(
	'rule_based' => array(
		'adapter' => 'Rules',
		'filters' => array(
			function($self, $params, $chain) {
				// Filter logic goes here
				return $chain->next($self, $params, $chain);
			}
		)
	)
));

##Credits

###Tom Maiaroto

The original author of this library.

Github: tmaiaroto

Website: Shift8 Creative

##Weluse

Wrote the original Rbac adapter.

Github: dgAlien weluse

Website: Weluse

##rich97

Modified the original Rbac adapter, added some tests and wrote this version of the documentation.

Github: rich97

Website: Enrich.it

li3_access's Issues

Allow match option in roles to be a closure.

Fix the regex match conditions in AuthRbac::parseMatch()

Right now when using the shorthand syntax to match a request things like this will set the controller and action:

'Test*:ac*ion'

You shouldn't be able to combine the match all with the controller/action string.

Add tests for denying a request manually

As described in the README.

Make 'requester' default to '*'.

Right now requester is a required parameter for roles, make it so that is doesn't have to be specified.

Documentation: Access::config('simple') syntax error.

Missing array() declaration.

Go over docblocks.

Things have changed a fair bit since I started working on this project. The doc blocks need to be checked to ensure they are still relevant, clear and accurate.

Allow some sort of filter or conditions behaviour.

As of right now it's possible to add anonymous functions to the match conditions. However if one of these functions returns false or void then the role is not matched and the message and redirect options are not set. I would like to keep this behaviour, but I would also like to set some additional conditions that can match the role yet still deny/allow access.

Closures in allow and match conditions need documentation.

Create wildcard it represent an unauthenticated requester.