Gustavo Narea wrote:
> Hi everybody.

Hi Gustavo, thanks for taking the time to write this....

> I'm working on the authorization framework for TurboGears 2, which is based 
> on 
> repoze.who, and I'm planning on making it TurboGears-independent, so that 
> more 
> developers may take advantage of the framework. In fact, it can be used 
> outside of TG with a couple of minor modifications.
> But instead of starting a new independent project, I would like to work 
> closely with repoze.who.


> I find it wise to keep repoze.who independent of authorization-related tasks, 
> but it's unavoidable to keep the authorization system independent of the 
> authentication. You can use repoze.who without tgext.authorization, but the 
> opposite is impossible (its core functionality works as a repoze.who metadata 
> provider).
> The consequences are that while documenting tgext.authorization I have to 
> document the repoze.who functionality I mention in the former and it'd be a 
> bit annoying to maintain plugins for both frameworks (if I maintain a 
> repoze.who LDAP plugin, should I start a new project just to add support for 
> tgext.authorization and make it work in the tgext.authorization.plugins 
> namespace?).

I'd like to understand this a little better.

In the authorization stuff in repoze.bfg I have a "repoze.who security policy"
that assumes a couple of things:

- A "security policy" checks object "acls" against "principal" info (group and
user names).

- People make declarations about their views, protecting each with a permission.
 An acl makes an assertion about which users or groups ("principals") possess
which permission against some model object.

- a sequence of group identifiers will be passed in the identity using a r.who
metadata provider that puts stuff into identity['groups'].  The combination of
identity['repoze.who.userid'] and identity['groups'] forms the list of
principals checked by any found acl.

There is no other tie between the authentication framework (the security policy)
and repoze.who.  The documentation for the security policy lives in repoze.bfg.
  There is also a RemoteUserSecurityPolicy which does not require repoze.who;
instead it just relies on environ['REMOTE_USER'] as its sole principal;
everything else works the same.

For each of my customer projects that uses both bfg and repoze.who, I've found
it necessary to create one new metadata plugin to get the group information from
wherever it lives.  But I've not considered putting these back into repoze.who
or starting a project for them, because they are typically very simple (on the
order of maybe 10 lines of code each).  OTOH, they are always slightly different
from each other, because customers have weird requirements.

Are these plugins the bits of code that you believe we should consolidate into a

> I propose to keep developing the authentication framework independently, but 
> merge both documentations and both plugin namespaces. Specifically, I have 
> two 
> options in mind:
>   1.- Turn tgext.authorization into repoze.what ("who" -> authentication; 
> "what" -> authorization). But this won't solve the problem with the 
> documentation nor the plugins.

That'd be fine by me.

>   2.- Start a new project under a new namespace (possibly under repoze.*?), 
> made up of the modules {project}.authentication (former repoze.who), 
> {project}.authorization (former tgext.authorization), {project}.plugins as a 
> namespace for plugins (plugins may add {project}.authentication's 
> identifiers, 
> authenticators, challengers and/or metadata providers, as well as 
> {project}.authorization's group and/or permission source adapters) and 
> another 
> module that will act as the "glue" to enable authorization. Also, both 
> documentations would be merged.

To be honest, I'd like to keep authentication and authorization (at least
nontrivial-policy-based authorization) in separate packages in order to avoid
the fate of AuthKit, which tries to do both, and fails.  I think it's a bit too
much of a mental jump for some people to understand the difference between the
two without someone spelling it out for them, and package separation tends to do

That said, the idea of having a package (ala repoze.what) that contains who
metadata providers that provide group info along with authorization decorators
that actually use that info sounds fine to me.  I may not use the decorators
myself, but I could contribute my little snippets of group-metadata-provider
plugins to repoze.what were we to descend on some defacto standard about how
those plugins should put that info into the repoze.who identity.

Let's take a case at hand... In your LDAP scenario, you've written the LDAP who
plugin, now you need to choose where to put an LDAP groups metadata plugin.  It
*could* go into the LDAP plugin itself.  Or it could go in some separate package
like repoze.what.  In the case of LDAP it *might* be best to put the metadata
provider plugin into the LDAP plugin itself, because causing e.g. repoze.what to
require python-ldap might be painful due to its requirement that it wants to
compile against openldap libs.

In fact, now that I wrote that, I can't think of a reason, for any plugin of
significant dependenty complexity, why the metadata plugin shouldn't exist in
the package that provides all the other plugins.  Maybe we just need to
establish a loose standard for metadata provision.  We'd then put the
authentication stuff in some other package, and have the authenticators *use*
that standard, but each metadata provider which provides it would still live in
its respective who plugin package?

Please feel free to lobby more for some merging of these two things, as I may
not have my thinking straight about it, and might be missing some fundamental
problem with this strategy.

> Unfortunately, the documentation for tgext.authorization has been recently 
> included in TurboGears', and TG2 online docs are out-of-date at this moment. 
> So, if you want to learn more about tgext.authorization, you may download and 
> build the TG2 docs (check the auth tutorial):
> Of course, no offense would be taken if you prefer not to merge both projects 
> :)
> Cheers!

Repoze-dev mailing list

Reply via email to