The last time I wrote a missive about BFG security pluggability, I
talked about breaking the existing "security policy" into two things:
an authentication policy and an authorization policy and put some code
up to show how that could be done.
So, that's now done and on the trunk (which will become 0.9). There
is one authorization policy in there (that hardly anyone will replace;
it's the default), and there are a couple of authentication policies:
one which gets the REMOTE_USER from an upstream data source, and the
other one which gets user and group data from repoze.who.
Just to make sure it's possible and not insane, I've gone through the
exercise of creating an authentication policy that does not rely on
upstream data for its user and group info. While doing so, I had
a bit of an epiphany.
The API "authenticated_userid" is pretty funny. It's meant to return
the currently authenticated user id. But what *is* the user id? In
repoze.who and its father PAS, we try very hard to treat credentials
obtained from form logins in the same way that we treat credentials
obtained from cookies, and so forth. And logically, they're the same
sort of thing: there's data in the request that identifies the user.
However, mechanically they work quite differently. In particular, it
really deeply *matters* to people what forms look like and what data
is shown to the user and so forth, and as a result developers really
need to control the horizontal and vertical. In particular, it's not
very much fun to require them to deal at all with some authentication
framework *on the HTTP level* when they do form login integration.
So the issue becomes this: presumably in its current incarnation, the
"authenticated_userid" API should know about credentials obtained from
a form login when not using an upstream data source for user info
(like who). I mean, these credentials just any other set of
credentials really. But *which* form credentials should it find?
Presumably the user is going to write his own login form and handler;
everyone wants to do this. Do I really need to tell him to use
special form variables in order to play with the current
authentication policy? Or worse, get him to write both a form *and*
an authentication policy to do something custom. I think not.
Instead here's what we're going to do:
- People will write login forms and views.
- The views will use the authentication policy API to "remember" the
credentials if they're good. Their views will be 100% responsible
for checking the password against a database, and so forth in order
to be able to know whether it's kosher to do this.
That's it. The standard set of authentication policies will not be
responsible whatsoever for understanding credentials presented by form
logins. Instead, these policies will just be able to return headers
and interpret cookies and request headers on ingress; they won't deal
with form bodies at all. Period. To tell people how to integrate
form logins with this in this way is far easier than trying to get
them to wiggle the right wires to turn form stuff into "credentials"
interpreted by an authentication policy.
Thing are different for systems that need "single sign on" where a
single form represents a login for many backend systems. But many
applications don't require this, and it's just easier to do very
custom form integration when you don't need to deal with some other
framework on an HTTP level.
Repoze-dev mailing list