Hello, Chris!

On Friday October 31, 2008 18:18:08 Chris McDonough wrote:
> > Well, I'd say making it easy to configure is the second reason why I
> > decided to do it that way. But the main reason is that I realized that
> > under this authorization pattern (users, groups and permissions), if we
> > were going to have one adapter per supported source type, then we could
> > also make such adapters edit the sources they work on (either groups or
> > permissions) -- and then a Django Admin-like application for TG could
> > take advantage of this ability on every supported source type under a
> > common API.
> I understand why this is attractive.
> I mentioned in my last mail that I don't think member data management
> belongs in any who plugin.  I call this "member data management" rather
> than "authorization data management" because it's unlikely that any two
> existing frameworks will share exactly the same concept of what metadata is
> necessary to perform authorization, so it will need to be generalized out
> to "any metadata" to be useful within arbitrary frameworks.
> IMO, there should be three separate things:
>  - Metadata in some persistent store
>  - A who plugin that knows how to read, filter, and marshall specific
>    metadata into something that the application understands for
>    authorization purposes.
>  - A member data management application that knows how to read from and
> write into the metadata store.  It should be able to change arbitrary
> attributes of resources in the metadata store (or at least the subset of
> attributes that people care about for the application being created). 
> These might include non-authorization-related fields like email address,
> phone number, etc.
> I think there's some case for normalizing an API to manage
> authorization-related attributes (especially if you're replacing an
> authorization model in a framework), but I think that API should be kept
> independent of r.who entirely, as who is about integration rather than
> about suggesting authorization policy.

Yes, I totally agree.

> > Yes, I agree with you. But I think the "users, groups and permissions"
> > pattern is becoming a rather famous pattern, so hopefully many people
> > will feel like at home.
> I agree that these terms are used in most frameworks.  I *know* however
> that they may not be used to describe exactly the same things for any two
> already-existing frameworks, so I don't think there's any opportunity to
> limit the scope here, unless the goal is to *replace* some framework's
> authorization system rather than accomodate it.  I'm beginning to realize
> that this is probably the goal; trying to shift my mental model.

Yes, the goal is to replace the framework's authorization system, in case it 
provides one.

> > But I think it'll work here because it's a very simple API that doesn't
> > try to do anything advance at all. It just deals with simple many-to-many
> > relations between the following entities:
> >  * Users <-> groups: It's able to add or remove users from a given group.
> >  * Groups <-> permissions: It's able to add/grant or remove/deny
> > permissions to a given group.
> >
> > And it can also create, rename and delete groups and permissions. Nothing
> > more.
> That's great for TG2.  It'd also be adequate for repoze.bfg, although bfg
> would not use the "permissions" bit (only the groups bit).  It wouldn't fit
> Zope people's brains, however, because Zope has a concept of "roles", and
> might not work for Django either because Django has separate concepts of
> "user permissions", "group permissions", and "module permissions", and
> users are also expected to have a full name, and an email, and so on.
> In any case, the point is that existing authorization requirements vary
> wildly between frameworks.  I think if the goal is to provide some
> authorization framework that people can use to *replace* an existing
> authorization system, it's totally fine (although I might quarrel over
> terminology and suggest some extensions).  But if the goal is to
> *integrate* with existing authentication systems, it should probably be
> slightly less ambitious.

Yes, as I said above, the goal is to *replace* an existing authorization 

> repoze.who is not very ambitious because it's mostly about integrating with
> existing systems; not about replacing.
> That doesn't mean that something shouldn't exist that does give people who
> don't already have an authentication framework (ala "bare" Pylons) some
> drop-in thing that gives them one.


> > I think all of the actions above will be available on every supported
> > source. (When I started working on tgext.authorization, both groups and
> > permissions could have descriptions, but later I removed this "feature"
> > because it would turn into a headache depending on the source -- what
> > about htgroups files? The only thing you can define in such groups are
> > usernames, unless you insert descriptions as comments before every group
> > definition, which would be an awful solution)
> >
> > But you've hit the nail on the head! :) I think this *could* really be a
> > TG- specific thing.
> Right.  Or at least one that aims itself at frameworks that don't already
> have an authorization model.


> > Before I wrote this email, I think we didn't agree with two things:
> >   1.- You preferred to have several group/permission metadata providers,
> > instead of one MD provider that loads everything from many places. I
> > think this is resolved with so-called "source adapters" being able to act
> > as repoze.who MD providers - what do you think?
> Well, I dont quite understand how that's much different than before, but I
> also realize that you are sold on this idea and it really doesn't matter
> what I think about it, so I say go for it! ;-)

Great! :)

> >   2.- You didn't find a good idea to try to have these source adapters
> > able to edit the sources under a common API as you thought it'd not be
> > feasible.
> >
> > So, since the first issue is resolved (I think so) and if I made you
> > change your mind regarding the second issue, would you agree with the
> > creation of the repoze.what project as the successor of
> > tgext.authorization?
> I think it'd be great to name it something repozey, and I'd love to see
> code contributed into the repoze repo.  I don't think it's something I'd
> *personally* use or contribute to, because the systems I develop in already
> have authorization models that work slightly differently.  However, other
> folks might jump all over it if it existed, especially folks that are using
> a framework that doesn't already provide an authentication model.

I'm really glad to know that! ;-)

So I'll start the migration now!

Gustavo Narea <http://gustavonarea.net/>.

Get rid of unethical constraints! Get freedomware:
Repoze-dev mailing list

Reply via email to