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 Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
