Jani,<br><br>lol. :-) very cool. <br><br>Actually I thought a bit more about it - the fancy authentication should be done in the "U" component. We should just take care of the standalone mode to also handle something similar to "expect_user" xml method.<br>
<br>Then it could be written in whatever language (one could start off with my ruby-based "dumb UGA" for example) - and be easily tweakable and very loosely coupled...<br><br>anyway, I am very much looking to see your code :-)<br>
<br>/d<br><br><div class="gmail_quote">On Fri, Feb 15, 2008 at 10:34 PM, Jani Pirkola <<a href="mailto:jpirkola@gmail.com">jpirkola@gmail.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;">
Hi Dalien,<br><br>That is exactly what we did in realXtend! Except that we use timeout of 2 minutes :)<br>We have user authentication and avatar storage. User authentication is the web service for 1) and 2). Avatar storage is a web service where other viewers fetch the appearance of your avatar (mesh, skeleton, textures, animations, ...) and the url there is supplied by the sim (where each viewer send their urls). <br>
<br>The name of user in login screen is e.g. <a href="mailto:jani@somedomain.org" target="_blank">jani@somedomain.org</a>, and the avatar storage then provides Avatar's name to sim. <br><br>The avatar storage and user authentication will be put into opensim svn asap, but it may take some time to take them into use in opensim.<br>
<br>Jani<br><br><div><span class="gmail_quote">2008/2/15, Dalien Talbot <<a href="mailto:dalienta@gmail.com" target="_blank">dalienta@gmail.com</a>>:</span><div><div></div><div class="Wj3C7c"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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><span><br>/d</span><div><span><br><br><div class="gmail_quote">On Fri, Feb 15, 2008 at 5:15 PM, Diva Canto <<a href="mailto:diva@metaverseink.com" target="_blank">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>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><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">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>
</span></div><br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">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>
<br></blockquote></div></div></div><br>
<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>
<br></blockquote></div><br>