/ 
Authorization-RBAC-0.12
River stage zero No dependents
/ Authorization::RBAC

NAME

Authorization::RBAC - Role-Based Access Control system

VERSION

version 0.12

SYNOPSIS

use Authorization::RBAC;

my $conf = 't/conf/permsfromdbix.yml';
my $rbac = Authorization::RBAC->new( conf => $conf ); # add schema => $schema if DBIx backend

my $page  = $rbac->schema->resultset('Page')->search( name => 'add' , parent => 7 );
my $roles = ... function that returns the roles ...

if ( $rbac->can_access($roles, $page, [ 'create_Page' ]) ){
    # Role 'member' can access to Page /page/wiki/add
}

# add a cache
$rbac->cache($cache);

DESCRIPTION

Role-based access control (RBAC) is an approach to restricting system access to authorized users.

User -> Role(s)

Role -> Permission -> Object (Typeobj, unique) -> Operation

So you can apply a permission to an instance of a Object and not only on all the class of the Object.

La suite en Français ...

Pourquoi ce module: J'étais à la recherche d'un module pouvant assurer la protection des accès à des objets. J'ai bien trouvé des modules sur le CPAN qui semblait répondre au besoin mais il y avait toujours un détail, une approche qui ne me convenait pas. La plupart de ces modules répondent à la question 'Est-ce que ce rôle peut faire cette opération ?'. Par exemple 'Est-ce que le rôle 'anonyme' peut créer un commentaire ?' mais jamais à la question 'Est-ce que ce rôle peut faire cette opération sur cet objet ?', exemple : 'Est que le role anonyme peut créer un commentaire sur cette page ?'. De plus je souhaitais que ce système de permissions soit récursif si l'objet à protéger comportait un champ 'parent'.

Comment ça marche :

Actuellement Authorization::RBAC comporte un seul backend : DBIx

Définition des acteurs du système :

- Un Type d'objet : Ce peut être une 'Page', un 'Commentaire', 'Une pièce jointe' ...

- Opération : Il s'agit d'un action sur un Type d'objet'. ( 'Add_Page', 'Del_Comment')

- Un Objet : c'est une instance du Type d'objet. 'Page login', 'Comment n°33', ...

- Une Permission : c'est une opération sur un Objet. Elle peut être récursive.

- Un Role : Il hérite de Permission(s)

Pour accéder à un Objet, le(s) role(s) doit posséder une Permission répondant à une Opération par défaut. Pour cela l'Objet doit avoir une méthode 'ops_to_access' qui retourne le ou les Operations qui le protège (en fait une référence à un tableau d'Opération). Par exemple la méthode ops_to_access de l'Objet 'Page /' retourne ['view_Page'], ce qui signifie "Pour accéder à la Page / le role doit avoir la Permission view_Page sur Page /".

La méthode 'can_access' permet d'interroger le système:

my $access = $rbac->can_access($roles, $objet, $additional_operations );

Un Objet peut avoir une méthode 'parent'. Si c'est le cas alors 2 mécanismes s'ajoute au système de permission :

- L'accès à un objet est obtenu si l'accès est permit à tous ses parents. Par exemple, pour accéder à la Page '/admin/user/add', le(s) role(s) devra successivement accéder à '/', 'admin', 'user' et enfin 'add'.

- En second lieu une Permission peut être rechercher récursivement sur les parents de l'Objet.

Par exemple si nous avons les relations suivantes :

Page: /: ops_to_access: view_Page admin: ops_to_access: view_Page add: ops_to_access: create_Page

Pour accéder à l'Objet 'Page /admin/user/add', le(s) role(s) devra posséder des Permissions répondant à 'view_Page sur Page /', 'view_Page sur Page admin' et 'create_Page sur Page add'. Imaginons que le(s) role(s) ne peut accèder à l'Objet. Par exemple si le(s) role(s) ne possède pas la Permission 'create_Page sur Page add' alors la recherche de la Permission se fera aussi sur 'admin' puis sur '/'. Pour que cette règle s'applique il faut que la Permission ait une méthode 'inheritable' qui si elle retourne 1 rendra la Permission héritable par ses enfants. Si elle retourne 0 cela a l'effet inverse, ça signifie que le role n'a pas ou plus cette Permission.

Imaginons maintenant que les roles aient les Permissions suivantes :

Roles: administrateur: view_Page: Page_/: 1 inheritable: 1 Page_admin: 1 inheritable: 1 create_Page: Page_/: 1 inheritable: 1 anonymous: view_Page: Page_/; 1 inheritable: 1 Page_admin: 0 inheritable: 1

Ainsi lorsque l'on recherche si le role 'administrateur' peut accéder à / admin / user / add, on ne trouvera pas de Permission 'create_Page sur Page add' mais on la retrouvera sur le parent racine et cette Permission est héritable.

Attention car nous avons donné la Permission 'view_Page sur Page / héritable' à 'anonymous' donc si rien n'est fait il a aussi accès à /admin. C'est pourquoi Nous lui avons aussi donné la Permission 'Ne peut view_Page sur Page_Admin héritable'. Ainsi l'accès à /admin est bloqué.

CONFIGURATION

See t/conf/permfromdb.yml

And also Authorization::RBAC::Backend::DBIx

PROVIDED METHODS

can_access($roles, $objects, $additional_operations )

check_permission($roles, $objects, $additional_operations )

AUTHOR

Daniel Brosseau, <dab at catapulse.org>

BUGS

Please report any bugs or feature requests to bug-authorization-rbac at rt.cpan.org, or through the web interface at http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Authorization-RBAC. I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.

SUPPORT

You can find documentation for this module with the perldoc command.

perldoc Authorization::RBAC

You can also look for information at:

ACKNOWLEDGEMENTS

LICENSE AND COPYRIGHT

Copyright 2015 Daniel Brosseau.

This program is free software; you can redistribute it and/or modify it under the terms of either: the GNU General Public License as published by the Free Software Foundation; or the Artistic License.

See http://dev.perl.org/licenses/ for more information.