esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <>
Subject Re: Superuser column in table users
Date Mon, 21 Dec 2009 13:41:27 GMT
On Mon, Dec 21, 2009 at 1:52 PM, Ethan Jewett <> wrote:
> On (1): I haven't looked at the Lift role model, but obviously I need
> to do that. Anyone know a good book on the topic? ;-)

Look at the lift book on the web:

> On (2): It might not be a bad idea to run the entire authorization
> model off of pools. Some food for thought: Why not just have a whole
> namespace of pools that is locked to LDAP authorization groups? Why
> not manage ESME authorizations (when we actually have some) through
> the pools? We could have it be a configuration property to specify the
> pool associated with the admin role and privileges. If the deployment
> setup warranted, the admin role could be mapped to a pool created
> based on an LDAP authorization group.

This was always in the back of my mind as well.
> On the other hand, my thoughts on (2) might be a really bad idea.
> Authorization models are not my area. I'm much more up to speed on the
> authentication side.
> Ethan
> On Sun, Dec 20, 2009 at 6:18 AM, Richard Hirsch <> wrote:
>> There are two points that we have to consider:
>> 1) there is also a role model that is present in lift
>> 2) how would we integrate the idea of authorization groups if we had
>> access to ldap (my favored solution)
>> ( - although here
>> the problem may the association with MegaProtoUser
>> The use of the superuser is probably the easiest way to get started
>> with such an api but the two other means above are probably  better in
>> the long-term.
>> By the way, if we had a ldap solution, then we might have to rethink
>> our pool administration, but first things first. ...
>> D.
>> On Sat, Dec 19, 2009 at 8:08 PM, Ethan Jewett <> wrote:
>>> Sounds ideal as long as someone familiar with the user model (not me
>>> :-) can confirm that this column is being used in this manner.
>>> If it's not being used at all at the moment, then I could start
>>> building admin functions on top of it, but we'll find ourselves in a
>>> situation in which you can do things through the API that you can't do
>>> through the ui.
>>> There are also the questions of how the first super-user is added and
>>> whether we want more granular access controls around administrative
>>> functions. The later is probably a question for the future.
>>> Ethan
>>> On Saturday, December 19, 2009, Richard Hirsch <>
>>>> Just saw the column "superuser" in the "users" table.
>>>> Maybe this could be used to determine if user have special rights
>>>> during administrative functions for our APIs.
>>>> D.

View raw message