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 framework. > 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. Right. > > 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. Exactly. > > 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! Cheers. -- Gustavo Narea <http://gustavonarea.net/>. Get rid of unethical constraints! Get freedomware: http://www.getgnulinux.org/ _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
