Hello, Graham.

On Thursday November 27, 2008 11:07:00 Graham Dumpleton wrote:
> Why is it dependent on repoze.who? A nicely decoupled system would
> only need to know that authentication had succeeded which generally is
> identifiable by REMOTE_USER being set in the WSGI environment
> dictionary passed from outer middleware, 


On the one hand, because I wanted to take advantage of the repoze.who system 
to run certain authorization-related actions during the process of 
identification (this is, prepare the authorization system).

On the other hand, because REMOTE_USER (which isn't set by r.who) is not 
always enough and also some of the future features will rely on 
future/existing repoze.who plugins, for example:
 - I'll write an X.509-based repoze.who identifier which will authenticate the 
user if she has a valid SSL cert issued by a trusted Certificate Authority; 
also, there will be a r.who metadata provider which will load the properties 
of her certificate. Then, with r.what, you'll have X.509-based predicates [1] 
which will use the data loaded by the MD provider (e.g., "The user must work 
at ABC", "The user's certificate must have been signed by our own Certificate 
Authority").
 - Likewise, the repoze.who LDAP plugin will also load the attributes of the 
current user (e.g., Organization Units) and such data may be very useful for 
authorization through r.what predicates [1] (e.g., "Only the Human Resources 
department can access the payroll").

Trying to achieve the above independently of repoze.who will require much too 
more code/effort for the developer because she will have to (1) take care of 
the X.509/LDAP authentication (possibly using an authentication framework), 
(2) extract the attributes required by the predicates she's going to use and 
(3) pass such data to repoze.what so that the predicates can work. On the 
contrary, this way everything will work out-of-the-box.

Authentication and identification is absolutely independent of authorization, 
but authorization very often relies on identification. This is why the goal is 
to leave r.who as an independent authentication/identification-only project, 
but make an authorization framework based on its powerful and extensible 
identification system.

> where outer middleware has
> performed authentication, or even where it didn't and REMOTE_USER was
> set by a web server capable of doing authentication itself such as
> Apache.

For example, in such a situation, you'd just need to configure repoze.who with 
an identifier that takes that value as the userid, which is very trivial and 
authorization through r.what will work as usual.

I would have thought seriously about decoupling it if I knew of any limitation 
in the authentication and identification systems of r.who, but I can't think 
of a situation that cannot be even solved by extending it.

Cheers!

[1] http://static.repoze.org/whatdocs/Manual/Predicates.html
-- 
Gustavo Narea <http://gustavonarea.net/>.

Get rid of unethical constraints! Get freedomware:
http://www.getgnulinux.org/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to