Re: Core services design patern
Re: Core services design patern
- Subject: Re: Core services design patern
- From: Simon <email@hidden>
- Date: Mon, 8 Feb 2010 20:35:34 +0000
a bit late to the party, but for what it's worth....
we had exactly the same requirement (users that have access to many
different applications) ans we now use the EROpenID framework to
authenticate against google apps, and it works perfectly.
in our DB we have an entity that represents a user and a unique ID
that ties it to a google apps profile. whenever anyone tries to hit an
app they get bounced out to google to authenticate. google then
returns them to the app once authenticated with a token that lets them
in.
if i were starting again i'd use the same structure. even if we were
implementing our own identity provider i'd still use single sign on,
and open ID is just so easy with EROpenID i'd probably stick with
that.
simon
On 28 January 2010 22:25, Xavier Destombes <email@hidden> wrote:
> Hi list,
>
> This isn't a bug:)
> It's really sharing my point of view to see if I'm going in the right
> direction.
>
> I've got multiple web applications that share some common users.
> I was thinking about creating a core user application to provide the
> authentication service. Basically I'd like my "client" applications to
> forward the login and password to this core user app and get either
> "succeed" or "fail" (maybe a broader range of fail messages).
> I don't really need the entire user to be stored directly in the "client"
> apps, but I would sometimes need some attributes from the user object.
>
> My though was:
> -to create a framework to store an abstract class for the user
> -to extend this class within the core user app (basically just make them
> non-abstract)
> -to use the abstract class in the client apps (and eventually make only a
> couple attributes non-abstract at that level)
>
> That way I could make sure my object is really the same throughout the apps,
> at least they share a commun set of attributes.
> A client app could request a login for a user and store only a subset of the
> user.
>
> Am I reinventing the wheel?
> Is it a good direction?
> Is there a better way?
> Am I going crazy:)
>
> Thanks for sharing your 2 cents;)
>
> Xavier
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden