Admin-users, Integration modes

[Ethan Jewett <es...@gmail.com>]

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

Re: Admin-users, Integration modes

[Richard Hirsch <hi...@gmail.com>]

One idea might be to set the authorization to a non-existent group.

You could also edit the default.html page in templates-hidden so that
no UI is shown - just a message of your choice.

D.

On Sat, Dec 26, 2009 at 2:00 PM, Sig Rinde <si...@rinde.com> wrote:
> Any way to turn off the web interface (8080)?
>
> For prototyping we added a few lines to the ESME API that allows us to
> create a new ESME user from Thingamy when a new user is added there.
> Only nickname and return of token involved, which works.
>
> Thing is that no password is set so anybody can log on using those
> nicknames and no password to log on.
>
> Simplest solution (for now) would be to suppress the web interface :)
>
> A line in some file that we could comment out?
>
> Sig
>

Re: Admin-users, Integration modes

[Sig Rinde <si...@rinde.com>]

Any way to turn off the web interface (8080)?

For prototyping we added a few lines to the ESME API that allows us to
create a new ESME user from Thingamy when a new user is added there.
Only nickname and return of token involved, which works.

Thing is that no password is set so anybody can log on using those
nicknames and no password to log on.

Simplest solution (for now) would be to suppress the web interface :)

A line in some file that we could comment out?

Sig

Re: Admin-users, Integration modes

[Ethan Jewett <es...@gmail.com>]

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
APIs.

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
write).

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.

Ethan

On Sat, Dec 26, 2009 at 7:24 AM, Richard Hirsch <hi...@gmail.com> 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 <es...@gmail.com> 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
>>
>

Re: Admin-users, Integration modes

[Richard Hirsch <hi...@gmail.com>]

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 <hi...@gmail.com> 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 <es...@gmail.com> 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
>>
>

Re: Admin-users, Integration modes

[Richard Hirsch <hi...@gmail.com>]

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 <es...@gmail.com> 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
>