IMHO tackling the password authentication might be quite simple:<br><br>1) have a separate web service into which you login, and which returns you a 4-digit number, valid for, say, 15 minutes.<br>2) have a web service to answer the requests from the sims who will supply the hash from the client<br>
3) have the simulator forward the hash from the client to this service upon the user login - and get the pass/fail result from this server.<br><br>On a first look, this will be reasonably secure, easy to use, simple to code, and harder to crack than the web-single-sign-on proposal that I heard in the discussions some time ago.<br>
<br>the last name could be the domain name, and the exact method of the authentication/URL/whatnot could be stored in a TXT record for that domain.<br><br>Users with the higher level of paranoia might have an option on the backend of selecting a longer one-time-password for the simulator login.<br>
<br>What do you think of such an approach ?<br><br>/d<br><br><div class="gmail_quote">On Fri, Feb 15, 2008 at 5:15 PM, Diva Canto <<a href="mailto:diva@metaverseink.com">diva@metaverseink.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">dr scofield wrote:<br>
> that makes it rather easy for any of your UCI users to log in as any<br>
> other UCI user. if that's what you want, fine. were i a UCI user, i'd<br>
> not like that...<br>
><br>
> if you were planning on using the password field as well, that is<br>
> going to require some additional code at the UCI authentication<br>
> service side as the password is not being send in the clear by as a<br>
> salted MD5 hash, so you'd have to generate those for all your UCI users.<br>
><br>
>    cheers,<br>
>    dirk<br>
><br>
><br>
</div>We will use passwords, of course, that's how authentications get done<br>
these days. We'll have to figure out how to handle the MD5 hash if the<br>
campus authentication service doesn't do it. Of course, better would be<br>
if the credentials were entered at the site of the authentication<br>
service, which is how this usually works on the web: you want to login<br>
to your grades -> you're first redirected to the authentication service<br>
-> you come back to the grades system.<br>
<br>
In any case, what I really want is to let everyone in, UCI and non-UCI,<br>
and properly ACL things -- just like what happens on the web. OpenSim<br>
still doesn't have permissions, so that probably won't be done now. But<br>
when it has permissions, that's what we will want. This whole idea of<br>
having un-interoperable domains of users, each grid with its own domain,<br>
is not going to scale to the kinds of things universities want to do<br>
with virtual worlds; it's a major step *back* from what we got<br>
accustomed with the Web. We want interoperable ID domains, interoperable<br>
inventory (storage) domains, gridless and intergrid sim-to-sim TPs,<br>
external exposure of data for search engines, and all kinds of good old<br>
web openness, properly ACLed -- that's very clear.<br>
<div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br>