Started a wiki page already: http://cwiki.apache.org/confluence/display/ESME/Collaboration+with+Thingamy
Maybe everyone can add their respective tweets to the page D On Sat, Dec 26, 2009 at 7:24 AM, Richard Hirsch <[email protected]> wrote: > I'd like to suggest using lift roles. This will give us some level of > abstraction and will also be more in line with our proposed use of > ldap for user management. > > For more information regarding the use of roles in lift, I'd also > suggest looking at material on ldap for lift: > (http://jgoday.wordpress.com/2009/11/27/lift-ldap/). You can also look > at the code in git for more details. > > If you are thinking about single-sign-on, I'd suggest looking at CAS > (http://www.jasig.org/cas). An integration of CAS into lift has also > been discussed on the lift list. There is ample material on how to > integrate CAS into applications > (http://www.jasig.org/cas/client-integration). This integration is > also important for our integration into OFBiz which also supports CAS. > > If we are talking about a API for administration purposes that is > definitely should be separated from the others and associated with > special rights. > > @Ethan - why don't you create a new wiki page in the collaboration > section where we can all work together. > > Ideally, the authorization in lift could come from the container but I > never seen any discussion of this. > > The issue of user creation was also discussed during my meeting with > iks where they suggested using a ldap. > > What about this suggestion: > > 1. Use lift roles to deal with these administration tasks > 2. Use a special API to deal with the creation of users, tokens > (interim solution). This API would have methods to create users, > create tokens and get tokens for users. > 3. Have the ability to disable the Admin API if not desired. > 4. First prototype could have users in the role stored in a property > file. This is similar to tomcat's security realms > > D. > > > On Fri, Dec 25, 2009 at 3:46 PM, Ethan Jewett <[email protected]> wrote: >> Hi all, >> >> I've been discussing integration modes in Thingamy >> (http://www.thingamy.com/) with Sigurd Rinde (cc'd as I'm not sure if >> he's on the list). I think Mrinal has also been discussing like mad, >> but Mrinal and I haven't discussed with each other, so there may be >> some duplication of effort :-). >> >> Sig and company have put some work into a prototype integration of >> ESME into Thingamy and I've been thinking about additions to the API2 >> endpoint that would enable some of the use cases Sig has in mind. >> >> One such use-case is basically ceding control of user-creation and >> token-management to a third-party system (like Thingamy, or perhaps >> OFBiz). This would allow the third party system to integrate ESME >> directly and provide a user experience something like single-sign-on, >> but managed completely by the 3rd-party application. An admin user or >> group of users would be identified who would be given control over >> token-management for all users. >> >> Currently, after reading a bit about Lift roles, I'm leaning towards >> using a Lift role hierarchy for the first cut at this problem. >> Eventually, maybe we can use pools to drive the assignment of users to >> Lift roles. I need to look more into how we assign roles to users, as >> the Lift book isn't very clear on this, so this may take a week or so. >> >> Of course, we would not want an administrator to have this sort of >> control in general (the ability to grant access to users via the API), >> so the sort of admin who can do this should be a special type who is >> only used in integration scenarios, and not in a stand-alone server >> scenario. I'm thinking of the following Lift role hierarchy for the >> first cut: >> >> - super-admin >> - admin >> - integration-admin >> >> I'll try to draft up a prototype of this authorization setup and API >> methods, hopefully working with Sig and team to test it. >> >> Thoughts on whether or not this is a good way to go? Better ideas? >> >> Ethan >> >
