Gustavo Narea wrote:
>> I realize the main driver for the AuthorizationMetadata machinery is to
>> reduce configuration duplication. But maybe a better route would be to
>> come up with an alternate front-end to who configuration which deals
>> gracefully with duplicate paths and such that need to be shared between
>> configuration sections. (e.g. some variable-setting-and-resolving
>> machinery that could be used within who.ini).
> 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
- 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,
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.
>>> In tgext.authorization you have the following components:
>>> * A "source" is where your groups and/or your permissions are stored. It
>>> may be a "group source" or a "permission source".
>>> * A "group source" is a source that stores groups (Htgroups file, a
>>> database, ini file, etc).
>>> * A "permission source" is a source that stores permissions (a database,
>>> ini file, etc).
>>> * A "source adapter" is a tgext.authorization class that handles a given
>>> type of source.
>> Yeah. I don't think this is necessary (as per the above), but I don't
>> expect to dissuade you from doing it, given the amount of code and docs
>> already produced.
>> So I'll just note that calling "permissions" and "groups" out as
>> specialized metadata passed down through who is really a TG thing, and not
>> an "any framework" thing. No other framework I've used calls "permissions"
>> what you call them in TG2 (in Zope, they might be called "roles", although
>> I'm not sure there's a complete one-to-one mapping).
> Yes, I agree with you. But I think the "users, groups and permissions"
> 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.
> Hmm, after reading the code above, I think your suggestion of making them
> independent metadata providers will be a great idea. But, at this point, I
> think it's best to make it an alternate way, not the only one.
> For example, I would add the following method to the BaseSourceAdapter:
> class BaseSourceAdapter(object):
> """This is the base class for source adapters"""
> # ...
> def add_metadata(self, environ, identity):
> # because the "sections" in a "group source" are the groups
> # defined for the application, find_sections() will load into
> # the identity dict the groups to which the authenticated user
> # belongs
> if 'groups' not in identity:
> identity['groups'] = self.find_sections(identity)
> identity['groups'] |= self.find_sections(identity)
> So that groups/permission source adapters can also be used as independent
> repoze.who metadata providers, as in your example.
Right. Well, like I said, I don't expect to change your mind about having one
metadata plugin to rule them all, given the work you've put into it.
>>> And you also get a bonus: The ability to manage your groups and
>>> permissions under a source-independent API, either from your application
>>> or from an external program.
>> I'd strongly suggest holding off on a "one-API-to-rule-them-all"
>> metadata-mutation capability until you have at least four or five backends
>> that can be mutated this way. I've seen some truly horrific things come
>> out of conflating authentication / authorization with "member data
>> management" early-on, even if the member data being mutated is limited to
>> only authentication-and-authorization-related attributes; yes, I'm looking
>> at you, Plone. ;-) It's easy enough to code up an application to change
>> these things independently, and by reading the code and docs I can see that
>> it's not really a "core" functionality yet.
> You make a good point.
> But I think it'll work here because it's a very simple API that doesn't try
> 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
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.
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?
> 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! ;-)
> 2.- You didn't find a good idea to try to have these source adapters able
> 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
> 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.
Repoze-dev mailing list