[Opensim-dev] openid (other authentication methods)
Stefan Andersson
stefan at tribalmedia.se
Tue Dec 16 09:01:27 UTC 2008
I believe, based on quite a few discussions with quite a few people lately, that it's time we finally started thinking about and working on the backend architecture.
I propose we take the same "modularized and malleable" approach that has been so successful on the region side - which would in effect mean,
* an extensible plugin system (Hooking up to events, like in the region)
* support for several authentication sources (As plug-ins)
and
* support for several, co-existing and complementing, client and backend protocols (I've already suggested that we center on a good set of 'handlers' that can be re-used - it seems like a good unifying point.)
Given that we haven't done much on the servers anyway, I think that this is an golden opportunity.
By the way, another good thing with the 'handlers' approach is that that would, in theory, let you 'assemble' a server process by just choosing what handlers to register in it, so if you want to separate login from user (which makes big sense from a security standpoint) you could just configure two processes.
Best regards,Stefan AnderssonTribal Media AB > Date: Mon, 15 Dec 2008 17:11:39 -0800> From: aerowolf at gmail.com> To: opensim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] openid (other authentication methods)> > Would there be a major problem with allowing an X.509> client-certificate based authentication system? (No, it won't work> with the existing Linden client either.)> > -Kyle H> > On Mon, Dec 15, 2008 at 5:39 AM, James Stallings II> <james.stallings at gmail.com> wrote:> > I am not JHurliman, but I have actually given this topic considerable> > thought. As I see things, there probably is no way to incorporate OpenID> > directly into the existing client.> >> > I dont let this concern me overmuch - I think constraining ourselves to> > existing client functionality is a certain way to allow our friends at> > Linden Labs to remain the defacto industry leaders of this technology.> >> > Now that that is out of the way, there are certain methodologies that I> > could employ to put an OpenID capability to work today:> >> > Scenario 1: Keep all accounts 'deactivated' by default (even when they are> > valid, active accounts), activating them only at such time as the OpenID> > authorization method I've embedded into the splash page is completed. Once> > that embedded authorization procedure is completed, the account would be> > enabled, and login would procede as normally occurs with the client.> >> > Scenario 2: All login procedures as per usual; OpenID kept on file for for> > positive identification on an as-needed basis where such things are> > relevant: access to mature content, proof of ownership of assets, resolution> > of complaints, etc.> >> > Scenario 3: External authentication layers that might be built on top of> > e.g., Hypergrid or OGP, which cant really be explored at present because we> > have no support for authenticating via OpenID.> >> > These are just three that occur to me off the top of my head. I think all> > represent use cases that are desirable here and now. We simply lack the> > tools to implement them at present. All that remains is that some> > trailblazing group put the tools in the hands of users.> >> > Will we blaze that trail? or will we read about who already has on the> > Linden blog?> >> > I say +100, get this patch in trunk. ASAP.> >> >> > Cheers> > James> >> >> > On Mon, Dec 15, 2008 at 7:03 AM, Sean Dague <sdague at gmail.com> wrote:> >>> >> Hurliman, John wrote:> >> >> >> > A clarification on the patch, this adds OpenID provider support to user> >> > server. It does not turn the user server into an OpenID consumer. I think> >> > OpenID grid login is a very interesting discussion that should take place on> >> > the mailing list, but what this does is allow you to prove ownership of an> >> > avatar on a grid. You could leave a comment on a blog using your avatar> >> > identity, for example. The main reason for the patch is to pave the way to> >> > building a secure hypergrid. Now that OpenSim is evolving into a federated> >> > grid model it's critical to be able to carry identity around the metaverse.> >> > I also have a patch for the distributed asset service that authenticates all> >> > inventory and asset transactions against the user server and allows> >> > whitelisting/blacklisting of foreign grids (will be committed very soon> >> > after some cleanup).> >>> >> Could you explain that authentication flow with the existing client?> >> While this patch doesn't hurt anything, I'd really like to understand> >> where this is going before we commit something like this.> >>> >> -Sean> >>> >> --> >> Sean Dague / Neas Bade> >> sdague at gmail.com> >> http://dague.net> >>> >>> >>> >> _______________________________________________> >> Opensim-dev mailing list> >> Opensim-dev at lists.berlios.de> >> https://lists.berlios.de/mailman/listinfo/opensim-dev> >>> >> >> >> > --> > ===================================> > The wind> > scours the earth for prayers> > The night obscures them> >> > http://osgrid.org> > http://del.icio.us/SPQR> > http://twitter.com/jstallings2> > http://www.linkedin.com/pub/5/770/a49> >> > _______________________________________________> > Opensim-dev mailing list> > Opensim-dev at lists.berlios.de> > https://lists.berlios.de/mailman/listinfo/opensim-dev> >> >> _______________________________________________> Opensim-dev mailing list> Opensim-dev at lists.berlios.de> https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081216/7eec8160/attachment-0001.html>
More information about the Opensim-dev
mailing list