[Opensim-dev] openid (other authentication methods)

Wed Dec 17 04:49:50 UTC 2008

May I suggest some possible use-cases, so that the design doesn't
inadvertently exclude them?

TLS authentication requires obtaining information from the TLS session
-- specifically, it requires obtaining the certificate with which the
client authenticates.  (I would recommend not relying on just the
Subject, but also the issuer and extensions -- which means that
implementing it as a CGI script is probably not really all that
useful, unless the webserver provides the full client-presented
certificate to the CGI program.)  Once the certificate is obtained,
the authentication information should be extracted therefrom.  The
use-case is that the client has a certificate issued by a CA that the
login/user server trusts (this CA perhaps even run by the user
server).  The certificate itself identifies which account to look at,
though it does not necessarily have to have the "firstname lastname"
approach taken in the current SL-grid model.

OpenID authentication requires an online connection to the OpenID
provider, and allows one to "own" an identity that can be proven
elsewhere on the 'net.  This requires an OpenID client in the
authentication server/user server, atop the OpenID provider that the
patch provides.  This identity should be linked to one avatar (though
it would likely be useful to allow a one-OpenID-to-many-avatar
configuration, as well as [for business accounts, for example customer
service] one-avatar-to-many-OpenID).

I'm certain that there are others (such as a Windows Active Directory
login mechanism, or a UNIX PAM-like login mechanism).

So, basically, what this means is that the authserver needs to be able
to handle its own network connection to the client (taking over the
current UserServer duty), needs to be able to accept any arbitrary
information over that connection, needs to be able to do whatever it
wants with that information, and eventually figure out how to
associate that authentication credential to a UserServer identity.
Then, it needs to set whatever on the back end so that the other
services know that the AuthServer has blessed the connection.

-Kyle H

On Tue, Dec 16, 2008 at 1:01 AM, Stefan Andersson <stefan at tribalmedia.se> wrote:
> 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 Andersson
> Tribal 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
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>