Add Rbac support (Integration with zfcrbac) about bjyauthorize

[Ocramius]

I'd probably go with an interface that abstracts AuthorizeAcl and AuthorizeRbac, but that takes some time since currently, all providers also give us roles that work with Acl.

Integrating with ZfcRbac seems a bit weird, since both modules support the same logic. It can be done eventually, but I don't see where the advantage (over simply using ZfcRbac in such case) is.

[neoglez]

mmm, I agree with "but I don't see where the advantage (over simply using ZfcRbac in such case) is".

On the other hand, this module is called Authorize, so why support only ACL (wich is a totally different concept -more desktop- as RBAC -more web) ??
...and wrapping the rbac logic in acl logic ("currently, all providers also give us roles that work with Acl")? ...well, doesn't sound so cool

[Ocramius]

@neoglez that's because:

1. when the module was thought, we didn't have the RBAC component
2. it has to be thought again eventually.

This can work if we define a config as following:

return array(
    'bjyauthorize' => array(
        'authorization_services' => array(
            // ze number is ze priority
            'BjyAuthorize\Service\AclAuthorize' => 1000,
            'BjyAuthorize\Service\RbacAuthorize' => 2000,
        ),

        'BjyAuthorize\Service\AclAuthorize' => array(
            // previous bjyauthorize config
        ),

        'BjyAuthorize\Service\RbacAuthorize' => array(
            // new rbac config
        ),
    ),
);

This obviously allows having a number of authorization services based on your own custom techniques. Since they are also attached as listeners, authorization can be event driven.

[neoglez]

Looks very flexible :)
I like the idea +1, i'll try to work on it

[Ocramius]

@neoglez please work only on the UML first. I still need to wrap my head around it, but it should be very simple.

Things to take into account:

• is the authorization service in the chain capable of acting on a given role/resource?
• should the authorization service break the chain on failure (basically black/whitelisting)

We need a simplified interface for authorization services. Something like following may work:

interface AuthorizationServiceInterface
{
    public function hasResource($resource);
    public function isAuthorized($resource);
}

The guards should be generalized to use only this interface, and configuration of the guards should be decoupled from configuration of the resources.

I will gladly add a milestone for 2.0.0, but the steps for decoupling the guards are what we already need for 1.3.0

[Ocramius]

Closing, see #112