Zend\Authentication changes

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Zend\Authentication changes

EvanDotPro
Hi all,

Hope everyone had a great holiday. I think it's about time for us to
start making some noise on the list again after a brief period of
hibernation over the holidays. :)

After some initial work on my EdpUser module
(https://github.com/EvanDotPro/EdpUser), I've ultimately had to
replace my usage of Zend\Authentication with EdpUser\Authentication to
support what I believe to be moderately common use-cases. I think it
might be worth updating Zend\Authentication to better handle a wider
spread of authentication use-cases.

My thought is to refactor Zend\Authentication to make use of
Zend\EventManager, and have adapters be listeners to an 'authenticate'
event. The main changes would be:

- Authentication adapters would be event listeners
- Multiple authentication adapters could be attached in various orders
(priorities)
- Each authentication adapter would have its own storage to keep track
if it has been satisfied across requests.
- Authentication adapters could return a Response to interrupt the
authentication process with something like a redirect to a third party
site (Google, Facebook, etc)

I have an unfinished (yet functional) proof of concept in EdpUser right now:

https://github.com/EvanDotPro/EdpUser/tree/master/src/EdpUser/Authentication

Here is a very rough example of how an adapter for authenticating with
GitHub might look:

https://gist.github.com/eb18537ca9363273922d

I'm curious what everyone thinks about this approach and if anyone has
any alternative or supplemental ideas in this area. The con here is
that we introduce a dependency on Zend\EventManager for using
Zend\Authentication... However, I think the advantages far outweigh
the added dependency.

---
Evan Coury
http://blog.evan.pro/

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Zend\Authentication changes

Marco Pivetta
Hey Evan!
As already said on IRC, this stuff is great and I like the approach.
Just wondering if your idea is about refactoring the entire component
(which is what I got from this post so far) or just writing a "chained"
Authentication Adapter. What's the direction for this refactoring?
Also, if your idea is about refactoring the entire Zend\Authentication,
what would the approach be? The current approach is:

$authentication = new Zend\Authentication\AuthenticationService();
$adapter = new My\Authentication\Adapter\Github();
$result = $authentication->authenticate($adapter);
if($result->isValid()) {
    echo "Hello admin! Welcome back!";
}

Would this change? A chained adapter would keep the code above untouched,
while having adapters within the service would change the
#authenticate(Adapter $adapter) method signature.
With your code it looks something like:

$authentication = new My\Authentication\AuthenticationService();
$authentication->addAdapter($di->get('some-auth-adapter-for-github')); //
the service could also just come from the locator
$response = $authentication->authenticate(new
Zend\Authentication\Request($stuff));
if($response instanceof Zend\Authentication\Response) {
    $response->send(); //redirects and whatever :)
} else {
    //What should we check for? Should we eventually always return an
authentication response as with zf1?
}

Pros of old approach: less code and response object is always an auth
response (no type checking)

Pros of new approach: authentication can come from a di locator


I'd always return some kind of authentication response and put the response
of the last adapter in it...
Any thoughts? :) I like the new concept if the fix about the mixed
parameters is applied (I don't like "mixed"... anywhere) :D


Marco Pivetta

http://twitter.com/Ocramius

http://marco-pivetta.com



On 4 January 2012 18:01, Evan Coury <[hidden email]> wrote:

> Hi all,
>
> Hope everyone had a great holiday. I think it's about time for us to
> start making some noise on the list again after a brief period of
> hibernation over the holidays. :)
>
> After some initial work on my EdpUser module
> (https://github.com/EvanDotPro/EdpUser), I've ultimately had to
> replace my usage of Zend\Authentication with EdpUser\Authentication to
> support what I believe to be moderately common use-cases. I think it
> might be worth updating Zend\Authentication to better handle a wider
> spread of authentication use-cases.
>
> My thought is to refactor Zend\Authentication to make use of
> Zend\EventManager, and have adapters be listeners to an 'authenticate'
> event. The main changes would be:
>
> - Authentication adapters would be event listeners
> - Multiple authentication adapters could be attached in various orders
> (priorities)
> - Each authentication adapter would have its own storage to keep track
> if it has been satisfied across requests.
> - Authentication adapters could return a Response to interrupt the
> authentication process with something like a redirect to a third party
> site (Google, Facebook, etc)
>
> I have an unfinished (yet functional) proof of concept in EdpUser right
> now:
>
>
> https://github.com/EvanDotPro/EdpUser/tree/master/src/EdpUser/Authentication
>
> Here is a very rough example of how an adapter for authenticating with
> GitHub might look:
>
> https://gist.github.com/eb18537ca9363273922d
>
> I'm curious what everyone thinks about this approach and if anyone has
> any alternative or supplemental ideas in this area. The con here is
> that we introduce a dependency on Zend\EventManager for using
> Zend\Authentication... However, I think the advantages far outweigh
> the added dependency.
>
> ---
> Evan Coury
> http://blog.evan.pro/
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Zend\Authentication changes

ralphschindler
In reply to this post by EvanDotPro
On 1/4/12 11:01 AM, Evan Coury wrote:

> Hi all,
>
> Hope everyone had a great holiday. I think it's about time for us to
> start making some noise on the list again after a brief period of
> hibernation over the holidays. :)
>
> After some initial work on my EdpUser module
> (https://github.com/EvanDotPro/EdpUser), I've ultimately had to
> replace my usage of Zend\Authentication with EdpUser\Authentication to
> support what I believe to be moderately common use-cases. I think it
> might be worth updating Zend\Authentication to better handle a wider
> spread of authentication use-cases.

> My thought is to refactor Zend\Authentication to make use of
> Zend\EventManager, and have adapters be listeners to an 'authenticate'
> event. The main changes would be:
>
> - Authentication adapters would be event listeners
> - Multiple authentication adapters could be attached in various orders
> (priorities)
> - Each authentication adapter would have its own storage to keep track
> if it has been satisfied across requests.
> - Authentication adapters could return a Response to interrupt the
> authentication process with something like a redirect to a third party
> site (Google, Facebook, etc)

I don't follow. Authentication adapters are only present during
authentication requests, not normal application requests.  Furthermore,
it seems like doing things during authenticate() is outside the scope of
Zend\Authentication.

> I have an unfinished (yet functional) proof of concept in EdpUser right now:
>
> https://github.com/EvanDotPro/EdpUser/tree/master/src/EdpUser/Authentication
>
> Here is a very rough example of how an adapter for authenticating with
> GitHub might look:
>
> https://gist.github.com/eb18537ca9363273922d
>
> I'm curious what everyone thinks about this approach and if anyone has
> any alternative or supplemental ideas in this area. The con here is
> that we introduce a dependency on Zend\EventManager for using
> Zend\Authentication... However, I think the advantages far outweigh
> the added dependency.

Well, I'd have to disagree.  Currently Zend\Authentication has zero hard
dependencies on other components.  The goal here is that there is a very
small blueprint for what Authentication should look like. In fact, I'd
say it is probably one of the more succinct API's we have:

   $auth = new Zend\Authentication\AuthenticationService;
   $auth->hasIdentity();
   $auth->getIdentity();
   $auth->clearIdentity();

   // roles and responsibilities of $auth:
   //   * coordinate long term storage
   //   * provide api for authentication strategy

   // then:

   $authStrategy = new Some\Auth\Strategy; // implements Adapter
   $result = $auth->authenticate($someStrategy);

   // roles and responsibilities of $authStrategy
   //   * produce a result
   //
   // notes:
   //   this only happens during an authentication request,
   //   not on every request

As I count it, there is literally, (on an authentication request), 1
input and 1 output.  It doesn't get much simpler than that.  Also, there
are zero dependencies, so this component is very standalone, making
usage, consumption and extension trivial.

What you're looking to do here, and correct me if I am wrong, is use the
EventManager as some kind of intra-object messaging system.  Since there
is a single method here, with one input and one output that can be
called multiple times btw, why do we need to interrupt that one method
with a message passing system?  Explain to me the value there.

Moreover, I am not sure I am seeing any value in adding in the
RequestDescription and ResponseDescription types.  Where will those be
used (interchangeably) with some other system?  What real value does it add?

It seems to me that this kind of solution is best suited for an
EdpAuthentication module.  All that would need to happen is that you do

class EdpAuthentication\Service\Authentication extends Zend\Auth\Auth {
    public function authenticateEvent(AuthEvent $event) {}
}

At the end of the day, it seems like you're trying to introduce
Application layer concerns into Zend\Authentication, instead of creating
a "_application_ module" and consuming Zend\Authentication to solve this
applications specific multi-auth problem.

So, all that said, we need to consider what growing the API, and
introducing EventManager and this Request\Response nature to this
component is going to do to the already standalone, trivial to use,
consume and extend component.

-ralph

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Zend\Authentication changes

ralphschindler
In reply to this post by Marco Pivetta
> Pros of old approach: less code and response object is always an auth
> response (no type checking)
>
> Pros of new approach: authentication can come from a di locator

Authentication can already come from a $di container.

   $a = $di->get('authentication-service');
   if ($a->hasIdentity()) {
      $user = $a->getIdentity();
   }

Or, during an authentication request (like /auth/login):

   $a = $di->get('authentication-service');
   $result = $a->authenticate(new DbTableAdapter( ... );
   if ($result->isValid()) {
      ...
   }

> I'd always return some kind of authentication response and put the response
> of the last adapter in it...
> Any thoughts? :) I like the new concept if the fix about the mixed
> parameters is applied (I don't like "mixed"... anywhere) :D

-ralph



--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Zend\Authentication changes

Antoine Hedgecock
I must agree with ralph and i honestly cannot find a use case for implementing an event driven authentication service like you have.

tho i do think that the authentication service should be updated because it impose restrictions on developers.
E.g no new error code can be specified that are lower then -4   my current implementation to allow new error codes https://gist.github.com/1566367

Best regards
Antoine Hedgecock
Senior developer / Server technician
PMG Media Group AB
Tel: currently unavailable

On Jan 5, 2012, at 5:10 PM, Ralph Schindler wrote:

>> Pros of old approach: less code and response object is always an auth
>> response (no type checking)
>>
>> Pros of new approach: authentication can come from a di locator
>
> Authentication can already come from a $di container.
>
>  $a = $di->get('authentication-service');
>  if ($a->hasIdentity()) {
>     $user = $a->getIdentity();
>  }
>
> Or, during an authentication request (like /auth/login):
>
>  $a = $di->get('authentication-service');
>  $result = $a->authenticate(new DbTableAdapter( ... );
>  if ($result->isValid()) {
>     ...
>  }
>
>> I'd always return some kind of authentication response and put the response
>> of the last adapter in it...
>> Any thoughts? :) I like the new concept if the fix about the mixed
>> parameters is applied (I don't like "mixed"... anywhere) :D
>
> -ralph
>
>
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Zend\Authentication changes

EvanDotPro
Okay, fresh reply...

Per feedback here and on IRC, I've refactored the authentication layer
in EdpUser to make use of a chained adapter and still utilize the
stock Zend\Authentication\AuthenticationService.

https://github.com/EvanDotPro/EdpUser/commit/1ca003463efb133a82f7aeb0b2e0a8e56ac8c287

One much requested feature is that only the ID of a user is stored as
the identity in the session, and when fetching the identity, it would
be resolved to the corresponding entity/model. In my original proposed
changes, this was easy to do in a very dynamic way that was not
implementation specific: the job of resolving the identity from one
thing to another could be handled by an attached listener (no attached
listeners == leave it alone, still functions as it did before).
However, by trying to work out something like this around the current
Zend\Authentication\AuthenticationService, I had to implement a
decorator around the AuthenticationService storage adapter.

Personally, I'm not opinionated enough on supporting multi-factor
authentication in Zend\Authentication to spend a lot of time or effort
convincing everyone, so if the opposition is the loudest force, I'm
fine with simply leaving Zend\Authentication as it stands. However if
it turns out there is any demand/interest in adding such support, I'd
be happy to work with the community to come up with something awesome
that works for everyone. At this point, I'm satisfied now that I have
a pretty clean implementation in EdpUser that works for me and anyone
else using EdpUser who may require multi-factor authentication.

--
Evan Coury

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Zend\Authentication changes

Antoine Hedgecock
In reply to this post by EvanDotPro
I still dont know if Im replying correctly but i still think that the auth should be updated to PHP 5.3 because that would both solve the issue i had in my previous mail and also keep coding standards upp to date
Best regards

Antoine hedgecock
PMG Media Group AB

----- Reply message -----
From: "Evan Coury" <[hidden email]>
To: <[hidden email]>
Subject: [zf-contributors] Zend\Authentication changes
Date: Fri, Jan 6, 2012 8:06 pm


Okay, fresh reply...

Per feedback here and on IRC, I've refactored the authentication layer
in EdpUser to make use of a chained adapter and still utilize the
stock Zend\Authentication\AuthenticationService.

https://github.com/EvanDotPro/EdpUser/commit/1ca003463efb133a82f7aeb0b2e0a8e56ac8c287

One much requested feature is that only the ID of a user is stored as
the identity in the session, and when fetching the identity, it would
be resolved to the corresponding entity/model. In my original proposed
changes, this was easy to do in a very dynamic way that was not
implementation specific: the job of resolving the identity from one
thing to another could be handled by an attached listener (no attached
listeners == leave it alone, still functions as it did before).
However, by trying to work out something like this around the current
Zend\Authentication\AuthenticationService, I had to implement a
decorator around the AuthenticationService storage adapter.

Personally, I'm not opinionated enough on supporting multi-factor
authentication in Zend\Authentication to spend a lot of time or effort
convincing everyone, so if the opposition is the loudest force, I'm
fine with simply leaving Zend\Authentication as it stands. However if
it turns out there is any demand/interest in adding such support, I'd
be happy to work with the community to come up with something awesome
that works for everyone. At this point, I'm satisfied now that I have
a pretty clean implementation in EdpUser that works for me and anyone
else using EdpUser who may require multi-factor authentication.

--
Evan Coury

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Zend\Authentication changes

weierophinney
Administrator
-- antoine Hedgecock <[hidden email]> wrote
(on Friday, 06 January 2012, 10:16 PM +0100):
> I still dont know if Im replying correctly but i still think that the
> auth should be updated to PHP 5.3 because that would both solve the
> issue i had in my previous mail and also keep coding standards upp to
> date

Zend\Authentication is already updated to PHP 5.3.

Evan is asking about some feature changes he's interested in making, and
trying to determine (a) if they're desirable, and (b) how best to
incorporate them/introduce them to the library.


> ----- Reply message -----
> From: "Evan Coury" <[hidden email]>
> To: <[hidden email]>
> Subject: [zf-contributors] Zend\Authentication changes
> Date: Fri, Jan 6, 2012 8:06 pm
>
>
> Okay, fresh reply...
>
> Per feedback here and on IRC, I've refactored the authentication layer
> in EdpUser to make use of a chained adapter and still utilize the
> stock Zend\Authentication\AuthenticationService.
>
> https://github.com/EvanDotPro/EdpUser/commit/1ca003463efb133a82f7aeb0b2e0a8e56ac8c287
>
> One much requested feature is that only the ID of a user is stored as
> the identity in the session, and when fetching the identity, it would
> be resolved to the corresponding entity/model. In my original proposed
> changes, this was easy to do in a very dynamic way that was not
> implementation specific: the job of resolving the identity from one
> thing to another could be handled by an attached listener (no attached
> listeners == leave it alone, still functions as it did before).
> However, by trying to work out something like this around the current
> Zend\Authentication\AuthenticationService, I had to implement a
> decorator around the AuthenticationService storage adapter.
>
> Personally, I'm not opinionated enough on supporting multi-factor
> authentication in Zend\Authentication to spend a lot of time or effort
> convincing everyone, so if the opposition is the loudest force, I'm
> fine with simply leaving Zend\Authentication as it stands. However if
> it turns out there is any demand/interest in adding such support, I'd
> be happy to work with the community to come up with something awesome
> that works for everyone. At this point, I'm satisfied now that I have
> a pretty clean implementation in EdpUser that works for me and anyone
> else using EdpUser who may require multi-factor authentication.
>
> --
> Evan Coury
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]