esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <>
Subject Re: Admin-users, Integration modes
Date Sat, 26 Dec 2009 10:54:35 GMT
Ah ha! That LDAP blog gave me a pattern I was looking for, that will
allow us to do more fine-grained role-based authorization than the
built-in Lift roles allow. I'd prefer if there was a place to do this
that was guaranteed to run before the LiftRules.dispatch, but since
that doesn't appear to exist, I'll do it this way.

I agree with everything you said below except:

I think that this should probably be part of API2 and whether or not
it is "turned on" should be controlled by user authorizations. If a
company doesn't want it turned on, then they shouldn't allow access to
it (and it should be non-allowed by default). It works on a lot of the
same "resources", so I think it would be nice to keep everything in
one place rather than having two "user" resources in two different

Theoretically, I agree that we should use Lift roles, but when I tried
to hack it together last night, I ran into a couple of issues:

1. The Lift httpAuthProtectedResource method that all the examples use
to tie roles to actions in the application is not suitable for a
RESTful API approach, since it ties authorization to the resource
rather than the resource/method combination (translation: you can't
have a resource with different authorization roles for read and

2. Using LiftRules.httpAuthProtectedResource seems to require the use
of LiftRules.authentication to authenticate requests. Unfortunately it
looks like you can only define one authentication method per
application (I may be missing something here), and since the Twitter
API is already using Basic authentication, we can't use a different
method for the administration API parts of API2.

I've got an email drafted to the Lift list asking about this stuff,
but I want to work on it a while longer so that I can make sure I
understand as much as possible.


On Sat, Dec 26, 2009 at 7:24 AM, Richard Hirsch <> 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:
> ( 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
> ( 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
> ( 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 <> wrote:
>> Hi all,
>> I've been discussing integration modes in Thingamy
>> ( 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

View raw message