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
