On Mon, Dec 21, 2009 at 1:52 PM, Ethan Jewett <[email protected]> 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: http://the-lift-book.googlegroups.com/web/master.pdf?gda=R3nKxjwAAACbVhWZrDVxSOOuy5kZIfXdyBgOnnuacLcKGqxUsUzRNphQBWRFAWHsPl_3piZ--U79Wm-ajmzVoAFUlE7c_fAt > > 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 <[email protected]> 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) >> (http://jgoday.wordpress.com/2009/11/27/lift-ldap/) - 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 <[email protected]> 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 <[email protected]> >>> wrote: >>>> 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. >>>> >>> >> >
