[Catalyst] OpenID authentication

[Yuval Kogman]

On Sun, Nov 13, 2005 at 21:13:49 -0800, Benjamin Trott wrote:
> > So what we would really like is to turn the credential verification
> > process on it's head - first verify the ID, and then get the user
> > for that ID, as opposed to first get the user for the ID, and then
> > get the user
> > 
> > In this case the plugin, used on it's own, should be able to verify
> > an ID, but additionally it should do this:
> 
> I'm not sure what you mean by "used on its own." Do you mean, used outside
> of Catalyst?

No, without Catalyst::Plugin::Authentication - and thus not implying
anything about e.g. $c->user being an object which you can ask
questions, and so forth.

> I'm assuming that an auth store is something like a session plugin--is that
> right? My usage of this plugin basically goes like as described in the
> example in the POD docs:

An auth store is an object or class that provides several methods:

	get_user
	from_session

And has a name, and is registered in the catalyst application.

This store returns a user object that inherits
Catalyst::Plugin::Authentication::User. This class provides the
'supports' method, which you can use to introspect the user, e.g.:

	$user->supports( qw/password clear/ ); # implies an interface is available
	
	if ( $user->password eq $password ) { 
		# login successful
	}

Which is reallly just a cheap hack to emulate role-ish behavior.

A credential verifier is, autonomously of the store, something that
performs authentication. For example:
http://dev.catalyst.perl.org/repos/Catalyst/trunk/Catalyst-Plugin-Authentication/lib/Catalyst/Plugin/Authentication/Credential/Password.pm

This plugin has the 'login' method which accepts a user object, or a
user id, and a password.

If it got a user object it will check if the object supports any
known password scheme, and if this is OK, it will mark the user as
authenticated (Catalyst::Plugin::Authenticate::set_authenticated
sets $c->user, and puts the user object in $c->session if configured
to do so).

What we achieve here is a scheme where authentication and user
storage modeling are decoupled. Your plugin is designed in such a
way that it's very easy to plug it into existing code, but it neeeds
just a tiny bit more effort.

As I see it your plugin's job is to take either a user object or an
openid URI, and then verify it. If the ID is OK, it does
$c->set_authenticated( $user ). If it got an openid uri instead of a
user object it will call $c->get_user( $id ) (which goes to the
default store), and assuming the store can retrieve users by their
URI it will get a user object back, and mark it as authenticated
instead.

In this way your plugin gets integration with existing
functionality. For example, I can use a DBIC store and declare the
open_id column as my primary key, and then 'get_user' for that store
will return a object that might be used in conjunction with
C::P::Authorization::Roles.


> Does that make it clearer how the module can currently be used, and can
> interact with a session store?

Yes, but

	a) $c->req->{user} is now a Bad Thing(tm) (sri says so ;-)
	b) you can get this functionality for free, including user
	restoratoin on prepare, since the code to do that is already
	written

-- 
 ()  Yuval Kogman <nothingmuch at woobling.org> 0xEBD27418  perl hacker &
 /\  kung foo master: uhm, no, I think I'll sit this one out..: neeyah!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20051114/29824239/attachment-0001.pgp