Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of hirsch.dick@gmail.com
 designates 209.85.220.214 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=KXl+PFVLh6X//FTfnTr5f6NVBU0VSrDloJlctkimZLpTLen34xd3hn65CE6QwYYAVq
         aRSneb/uaE2JFbCItY6hMmN8+kEZLNdFsfNRnAZTOVxSLKXiA32vWxma4X4Anu+eKyhj
         RNeN6qb9+j7r/BgkxJW70g/RU1xe3kDKxGrGE=
MIME-Version: 1.0
In-Reply-To: <68f4a0e80912250646l5ee96a24y84c4946be9a399f7@mail.gmail.com>
References: <68f4a0e80912250646l5ee96a24y84c4946be9a399f7@mail.gmail.com>
Date: Sat, 26 Dec 2009 07:24:34 +0100
Message-ID: <fa2d9f450912252224x637ecfd5u7c542d321a28c98f@mail.gmail.com>
Subject: Re: Admin-users, Integration modes
From: Richard Hirsch <hirsch.dick@gmail.com>
To: esme-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 <esjewett@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:
>
> =A0- super-admin
> =A0 - admin
> =A0 - 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
>