2.0.0 RFC

[bjyoungblood]

BjyAuthorize 2.0.0 RFC

The current major plan for 2.0.0 is an overhaul of the module with a focus on abstraction, with the goal of supporting both Zend\Permissions\Acl and Zend\Permissions\Rbac.

This issue is aimed at determining the overarching goals, features, and other major changes or refactorings that will involve a major release.

This RFC is open to the public. If there is something you would like to see (or specifically not see) in BjyAuthorize 2.0.0, please comment here.

We will create new issues for items that are accepted or require more discussion.

Interface

The authorization service could be abstracted into following interface:

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

Which basically means that each authorization service is aware of its own identity roles

Concept

Given following config:

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
        ),
    ),
);

Two authorization services will be spawned within an AggregateAuthorizationService that is composed of an RbacAuthorize and an AclAuthorize.
These two services are put into a priority queue (maybe as event listeners?) and are checked in sequence each time hasResource or isAuthorized are called on the aggregate authorization service.

[bjyoungblood]

To begin, this has become more of a community module than anything I could have possibly hoped to create alone. I would like to open the floor to suggestions for a new "official" name for the module (though previous versions should remain available as BjyAuthorize, and the git history must remain intact).

[Ocramius]

@bjyoungblood I don't see any problem with BjyAuthorize as module name, but it could be FirewallModule or such eventually

[bgallagher]

Should it become part of ZF-Commons? Given the high grade code quality, popularity, and dependence on ZfcUser?

[bjyoungblood]

@bgallagher I would be -1 on any moving to ZF-Commons because of the general lack of interest from the majority of the ZF-Commons team. There was an RFC to do exactly this a while back, and it ended up being ignored/forgotten multiple times.

[Ocramius]

Please DON'T ever move it to commons. Most of the Zf-commons projects
choked in this RFC-mania.
On 10 Mar 2013 15:32, "Ben Youngblood" notifications@github.com wrote:

@bgallagher https://github.com/bgallagher I would be -1 on any moving
to ZF-Commons because of the general lack of interest from the majority of
the ZF-Commons team. There was an RFChttps://github.com/ZF-Commons/RFC/wiki/RFC:-ZfcAclto do exactly this a while back, and it ended up being ignored/forgotten
multiple times.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/112#issuecomment-14682240
.

[Ocramius]

I updated the original issue with what was discussed in #108

[neoglez]

+1 to "Please DON'T ever move it to commons. Most of the Zf-commons projects choked in this RFC-mania."

[neoglez]

I think this issue contributes here also to make things (ACL/RBAC) clear:
ZF-Commons/zfc-rbac#49 (comment)

[vahid-sohrabloo]

I think Rule provider to save in database in good feature

[PowerKiKi]

That's probably a silly question, but at first glance it would seems that BjyAuthorize and ZfcRbac are pursuing the same goals. Is there a fundamental difference (beside the obvious lack of ACL for ZfcRbac and lack or Rbac for BjyAuthorize) ?

If not, was it already considered to join effort ? I can't help but feel it's shame to split the community between two modules which looks so similar.

Also as a newcomer to ZF2 modules, I feel somehow more "safe" with something called ZF-Commons which makes it vaguely "official" (read "strong(er) community/support"). So my guess would be that it could benefit BgyAuthorize to move over there.

[Ocramius]

@PowerKiKi actually, so far, the ZF-Commons group has some good and some really poor-quality modules. ZF-Commons, as it stands right now, is a show stopper (for reasons explained above).

Yes, ZfcRbac and BjyAuthorize currently differ only in the backing Acl/Rbac systems.

I don't think that joining the repositories is a good idea.

1. that would mean getting under ZF-Commons - sl o o o o o w.

2. so far, the variety of available modules doing same things has been a blessing - it allows the end user to decide which to pick and what practices to use.

   Joining efforts is for sure a good idea. For example, I often ask @bakura10 to review PRs to this repository.

The number of forks/stars on BjyAuthorize should give you enough confidence to consider it interesting and/or worth your consideration.

If we can move on and let "politics" behind us, please consider adding your ideas to the proposed interfaces :)

[PowerKiKi]

@Ocramius thank for the quick reply. I am currently in the process to sort out which one are the good modules. And I am slightly confused/concerned by the varying quality seen in Zf-Commons, as you said yourself. Indeed the forks/stars count speak for themselves... However I'll try my luck with ZfcRbac for a while ;-)

Right now, I am afraid I am way too "newbie" to contribute to any of those projects. But I appreciate your invitation and will keep it in mind when I'll have slightly more experience.

[bakura10]

Hi,

I'm giving my opinion about this : I'm one of the few ZF 2 developers that think like PowerKIKI that naming is important. I am one of them, and I'm naturally more attracted by a module called "ZfcSomething" rather than "LldSomething". Power of naming is understimated by some people here. With time, we know some good people that make good modules. I know that Ocra_, Slm_, Spiffy_, Bjy_ will be good, maintainted and tested.

Saying this, I know too that ZF-Commons is not ideal. The RFC-thing, and a lot of unmainainted module (worse, even empty repositories ! I created an issue on ZfcBlog for instance to remove it) make it less professionnal. I'd be in favour of moving unmaintained modules outside this namespace, so that the account only contains high-quality modules.

Concerning this v2, don't you think it would be a good idea, if you plan to support Rbac, to join forces with Spiffy and ZfcRbac, so that we could find a good architecture to merge those two modules into one ? I'm pretty sure you could find great ideas on ZfcRbac (it's really great engineered). I find it confusing to have two high quality modules that does more or less the same thing. Maybe ZfcAuthorization (either a renaming of ZfcRbac, or a new module). If people want an "semi-official" prefix, no problem to create a module under Zfr (stands for ZF France). This way it's more an organization instead of people, and I don't require RFC or any thing (just good modules, tests, tag often...).

[PowerKiKi]

I don't mean to insist on this topic too much. But if Commons is the issue,
then why not take ZfcRbac out of it ? (for the hypothetically merged v2.0)

In my opinion the most important thing is the code and join forces if the
concepts and goals are the same (which seem to be the case).

Then if we can also makes everyone happy with an "official looking" name,
that would be a nice bonus.

Anyway I guess that's up to main developpers of both modules to find an
agreement if they have any interest in that.

[bakura10]

I'm for it too. It's already confusing and people always ask me : bjyAuthorize or ZfcRbac. If BjyAuthorize plan to have Rbac too let's create only one.

As an advantage, it will be easier to provide integration for other modules like Navigation if we have only one module.

ZfrAuthorization looks super cool and have official look =).

Envoyé de mon iPhone

Le 20 mars 2013 à 13:00, PowerKiKi notifications@github.com a écrit :

I don't mean to insist on this topic too much. But if Commons is the issue,
then why not take ZfcRbac out of it ? (for the hypothetically merged v2.0)

In my opinion the most important thing is the code and join forces if the
concepts and goals are the same (which seem to be the case).

Then if we can also makes everyone happy with an "official looking" name,
that would be a nice bonus.

Anyway I guess that's up to main developpers of both modules to find an
agreement if they have any interest in that.
—
Reply to this email directly or view it on GitHub.

[Ocramius]

@bakura10 ZfcRbac is forked off BjyAuthorize anyway. I think I can look at it and abstract something :) An (awesome) YUML diagram shall show this :D

[Ocramius]

I don't really care about the vendor name, personally. This is bjy's concepts and I'd personally prefer to keep it with @bjyoungblood's vendor because of the historical grounding of this awesome ideas :)

But anyway, can we please reboot from the API itself? Otherwise I'll start deleting comments.

[spiffyjr]

@Ocramius ZfcRbac is not forked from BjyAuthorize. It's entirely my own code. I'm really failing to see what BjyAuthorizeRbac version could provide that ZfcRbac doesn't (or couldn't). Why not keep the modules separate and focused with, perhaps, integration points for providers?

[bakura10]

@spiffyjr , I think the main point of having only one module (in addition of having more people work on the same module) would be to reduce confusion for people. I'm always having question about either choose ZfcRbac or BjyAuthorize (and as Rbac and Acl a lot of people can't see any difference between those two).

By having only one module it will be easier: just use ZfcAuthorize/BjyAuthorize/whateverAuthorize. And as we can have common interfaces in one module, it'll be easier for other module to offer integration too.

But maybe I'm wrong.

[spiffyjr]

That's fine, if we can make it work in a clean and efficient manner. As I'm using ZfcRbac in all of my projects (personal and professional) it gets support. All of my ZFC modules are maintained. Having a single common authorization module inside of ZF-Commons wouldn't necessarily be a bad thing.

Bjy, Ocramius, Bakura, me all working and collaborating on a single module means it would be well engineered, high quality, and maintained - exactly what ZF-Commons needs.

My 2c.

[bakura10]

+1. I'd be in favor of having ZfcAuthorize. Simply. I know ocramius is against that because of the RFC but well...

I think that the best way would be to keep ZfcRbac and BjyAuthorize so that people still using it can use it and creating ZfcAuthorize with a brand new architecture that could integrate with any security systems (Rbac/Acl).

[Ocramius]

@bakura10 I don't want it part of Zfc. If it's you, me and @spiffyjr it's ok, but Zfc? Meh.

@spiffyjr hmm... I was really convinced it was forked off because of the very similar architecture (probably was ZfcAcl at that time then).

Anyway, can we get back at interfaces? :) Should I close this one and create a new issue? Is anyone already having a clear idea of how to have the best of both worlds? Anything wrong with the interface suggested above?

[bakura10]

If it's you, me and @spiffyjr it's ok, but Zfc? => It's ok or it's not okey ? 💃

I'll think about those interfaces tomorrow :). I think you can keep this thread, no need to create another one ;-).

[Ocramius]

@bakura10 I'm fine with it, but Zfc has strict rules about RFC crap, and I really think it's a maze. Ask the others of that group eventually.

[bakura10]

But this has does not change until the time? I mean, maybe people will be a bit less restrictive now no ?

[Ocramius]

Probably. I do hope so.

[bjyoungblood]

Rather than combining the modules and causing everyone to have to deal with the rename, we could create a module that defines a set of common interfaces, but no implementations. That way, anyone who wants to be able to use both will be able to, but it (in theory) won't affect existing code.

That module could be ZfcAuthorization or ZfcWhatever, but only if the right people have commit access so that it can be maintained.

As far as moving to Zfc, I'm inclined to agree with @Ocramius. A subset of the modules may be well-maintained, but most of the people who are in charge of ZF-Commons don't seem to pay much attention to it. As I have mentioned before, there was already an RFC to include this module in Zfc and it was talked over for months, went into voting and then was ignored.

[bakura10]

Hi everyone,

I've tried to think about it, but unfortunately I'm not an authorization expert so I'm not sure I can really help you. However I like the idea of the AuthorizationService. However I see a minor problem here is about terminology: here you are speaking about $resource while in ZfcRbac the terminology is more about $permission. I think it's gonna be a bit hard to have something generic then.

ONCE AGAIN: In my current applicaiton I have sooo simple permissions that I've never had the chance to play with complex permissions, so I may be completely out of the topic, sorry about that.

How about extending the Authorization service so that we can register assertions too ?

interface AuthorizationServiceInterface
{
    public function hasResource($resource);
    public function hasRole($role);
    public function registerAssertion($resource, AssertionInterface $assertion);
    public function isAuthorized($resource);
}

As assertions may have dependencies having a plugin manager for this would be good:

'bjy_authorize'/'zfc_authorization' => array(
    'assertions' => array(
        'factories' => array(
            'My\Assertion' => 'Assertion\Factory'
        )
    )
);

For Identity I think we should limit this new module to ZF 2.1 so that we can take advantage of the Zend\Authentication\AuthenticationService that would be the only point to get logged identity, which should implement a common interface:

interface IdentityInterface
{
    public function getIdentity();
}

As both ZfcRbac and BjyAuthorize have concepts of guards/firewalls:

interface FirewallInterface
{
    public function build($rules);
}

interface RouteFirewallInterface
{
    public function isAuthorized($route);
}

interface ControllerFirewallInterface
{
    public function isAuthorized($controller, $action);
}

We should also some sort of event:

class AuthorizationEvent
{
    const EVENT_AUTHORIZED      = 'authorized';
    const EVENT_UNAUTHORIZED = 'unauthorized';
}

Those events would be triggered by firewalls, assertions... hence allowing us to easily plug strategy (return 403, redirections...).

EDIT : one thing I've always found confusing is that I use ZfcRbac BUT I've never used the concept of permissions, because the firewalls allow me to do what I want. Therefore, I always had the feeling to use it incorrectly because, to some extent, I do not use the core concept of the authorization system I'm using. When I read the code of Firewalls, in fact both firewalls (router and controllers) store the rules in an array, so it's outside the use of Rbac.

[zluiten]

Okay, just a small comment on the naming, since @Ocramius seems alone in his position :): I am strongly against moving it to Zfc too. I already regret that I choose to implement Zfc stuff in my application because of the inactivity.

[jaapio]

Is there any progress on this?

[bakura10]

Hi,

I don't know the status of BjyAuthorize, however I have released recently a complete refractor of ZfcRbac (v2). But it's only for Rbac model.

[Ocramius]

@bakura10 I know you do great work, but that's spam.

@jaapio no progress yet - I would start from scratch though.