OpenID for data portability in virtual world

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
(→‎Use a central OpenID provider)
m (Robot: Cosmetic changes)
 
(20 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 +
__NOTOC__
 +
{{Quicklinks}}
 +
<br />
 +
 +
{{proposal}}
 +
 +
[[User:Lulurun]]
 +
 +
== Agenda ==
 +
 +
To enable user avatar travel from a grid service to another grid service,
 +
There are 3 problems to be considered:
 +
# '''How to enable foreign user login - Authentication'''
 +
#* '''This is discussed in this page'''
 +
# (If a foreign user can login)[[Avatar portability version 2|How to get a foreign user's belongings]](including appearance, inventory)
 +
# [[Security vulnerability brought by non-check inventory service|Security]]
 +
 +
To achieve the 1st, client side changes are needed. SO, so far, I have
 +
only implemented the 2nd and the 3rd, and would like to explan my idea:
 +
 
== What is OpenID ==
 
== What is OpenID ==
 
For OpenID related knowledge:
 
For OpenID related knowledge:
Line 7: Line 27:
 
In virtual world,
 
In virtual world,
 
To enable a foreign user authentication, What I can imagine is that there are 3 ways can be used.
 
To enable a foreign user authentication, What I can imagine is that there are 3 ways can be used.
−
*Import account from one GridService to another
+
* Import account from one GridService to another
−
*Use a central OpenID provider
+
* Use a central OpenID provider
−
*UserServer(OpenSim) acts as both RP and OP
+
* UserServer(OpenSim) acts as both RP and OP - this is the '''final goal'''
 
Detailed explanations are following:
 
Detailed explanations are following:
  
 
=== Import (copy an account information from one to another) ===
 
=== Import (copy an account information from one to another) ===
−
[[Image:openid_auth_1.PNG]]
 
  
−
This is the most simple way, just copy an account from its original Gridservice to another, this can be done through webpages, and current OpenSim's Userserver already has a similar XMLRPC method (GetUserProfile) to do such thind, even though some security holes need to be filled.
+
This is the most simple way, just copy an account from its original Gridservice to another.
 +
 
 +
this can be done through webpages, and current OpenSim's Userserver already has a similar XMLRPC method (GetUserProfile) to do such thind, even though some security holes need to be filled.
 +
 
 +
* Advantages:
 +
*# Quick, direct solution, easy to develop / use.
 +
 
 +
* Disadvantage:
 +
*# The same user profile copied many times, can not manage them(in the case you change your profile in 1 gridservice, it does not affect other grids)
 +
*# User have to remember too many password(even though you can always use the same)
 +
*# If your name has been taken, you have to change to another - no name portability
 +
*# other bad points ...
  
 
=== Use a central OpenID provider ===
 
=== Use a central OpenID provider ===
  
 
Just like in the web world, there are already lots of website enabled both legacy login and openid login,
 
Just like in the web world, there are already lots of website enabled both legacy login and openid login,
−
*Example: https://sourceforge.net/account/login.php
+
* Example: https://sourceforge.net/account/login.php
  
 
UserServer can also support OpenID login, in this case, authentication can be delegated to OpenID providers.
 
UserServer can also support OpenID login, in this case, authentication can be delegated to OpenID providers.
Line 26: Line 56:
 
* Advantages:
 
* Advantages:
 
*# User auth information is stored only in 1 place.
 
*# User auth information is stored only in 1 place.
−
*# no worry about your favorate name has been take.
+
*# no worry about your favorite name has been take.
 
*# ... some other OpenID advantages
 
*# ... some other OpenID advantages
  
−
* Disadvantages:
+
* '''Disadvantages''':
 
*# Current client need to be changed.(ver 1-18-6 is OK)
 
*# Current client need to be changed.(ver 1-18-6 is OK)
 
*# In data portability theory [Avatar portability], not only the auth information, but also others (UUID, inventoryurl, asseturl) are needed.
 
*# In data portability theory [Avatar portability], not only the auth information, but also others (UUID, inventoryurl, asseturl) are needed.
−
**OpenID has 2 extensions:
+
*** OpenID has 2 extensions:
−
*## ax: http://openid.net/specs/openid-attribute-exchange-1_0.html
+
***# ax: http://openid.net/specs/openid-attribute-exchange-1_0.html
−
*## sreg: http://openid.net/specs/openid-simple-registration-extension-1_1-01.html
+
***# sreg: http://openid.net/specs/openid-simple-registration-extension-1_1-01.html
−
these 2 extensions supports OpenID user to store its additional information, but there are only a few OpenID providers enabled these functions.
+
*** These 2 extensions supports OpenID user to store its additional information, but there are only a few OpenID providers enabled these functions. as far as I searched,
−
as far as I searched,
+
***# only myopenid.com: https://www.myopenid.com/ enabled both extensions.
−
*## only myopenid.com: https://www.myopenid.com/ enabled both extensions.
+
***# yahoo.com does not support any of the 2 extensions.
−
*## yahoo.com does not support any of the 2 extensions.
+
  
 
=== UserServer acts as both RP(Relying Party) and OP(OpenID Provider) ===
 
=== UserServer acts as both RP(Relying Party) and OP(OpenID Provider) ===
 +
 +
UserServer can not only delegate an authentication to another UserServer, but also
 +
accept an incoming authtication request from another UserServer.
 +
 +
That means,
 +
* If a local user login to an UserServer, the UserServer use legacy way(password checking) to confirm the user's identity,
 +
* If a foregin user login to an UserServer, UserServer delegates the authtication.
 +
** user input its OpenID url(probably its Grid's UserServer url), then follow the OpenID authentication protocol -> [[Yadis for UGAI services discovery]]
 +
* When an authtication request comes, UserServer checks the user's identity, if OK, UserServer returns the user profile(include name, uuid, inventoryurl, asseturl).
 +
 +
 +
 +
* Advantages
 +
*# User auth information is stored only in 1 place.
 +
*# no worry about your favorite name has been take.
 +
*# ... some other OpenID advantages
 +
*# UserServer supports "UserAssetUrl", "UserInventoryUrl", "UUID" by standard
 +
*# Help the OpenID expansion, minor
 +
 +
* Disadvantages
 +
*# More changes needed
 +
*# Current OpenSim's httpserver is not fully functional(environment variable supports, module supports, compared with apache)
 +
*** you can choose '''OpenUGAI''':http://openugai.sourceforge.net/, that is born for this purpose.
 +
 +
=== FOAF+SSL ===
 +
 +
You should consider FOAF+SSL for this:
 +
 +
http://esw.w3.org/topic/foaf+ssl
 +
 +
A FOAF is a standardised way to provide a global avatar / profile. It also can easily link to other data files.
 +
 +
SSL can be used for security and access control, where necessary.
 +
 +
This is a relatively new technology, but should meet all the long term needs discussed above. However, it is backwards compatible with OpenID, so if you choose to go down that route you can test out a passwordless experience.
 +
 +
Also given the richness and extensibilty of FOAF, it is relatively easy to build applications on top of your FOAF, such as an economy and currency system, web bases social networks and external activity streams.

Latest revision as of 20:42, 3 March 2012

Languages Languages: 

En.png English


48x48

This article or section is a Proposal
It does not represent the current state of OpenSim, but is an idea for future work in OpenSim. Please feel free to update this page as part of the proposal discussion.
User:Lulurun

[edit] Agenda

To enable user avatar travel from a grid service to another grid service, There are 3 problems to be considered:

  1. How to enable foreign user login - Authentication
    • This is discussed in this page
  2. (If a foreign user can login)How to get a foreign user's belongings(including appearance, inventory)
  3. Security

To achieve the 1st, client side changes are needed. SO, so far, I have only implemented the 2nd and the 3rd, and would like to explan my idea:

[edit] What is OpenID

For OpenID related knowledge: http://en.wikipedia.org/wiki/OpenID

[edit] Foreign user login

In virtual world, To enable a foreign user authentication, What I can imagine is that there are 3 ways can be used.

  • Import account from one GridService to another
  • Use a central OpenID provider
  • UserServer(OpenSim) acts as both RP and OP - this is the final goal

Detailed explanations are following:

[edit] Import (copy an account information from one to another)

This is the most simple way, just copy an account from its original Gridservice to another.

this can be done through webpages, and current OpenSim's Userserver already has a similar XMLRPC method (GetUserProfile) to do such thind, even though some security holes need to be filled.

  • Advantages:
    1. Quick, direct solution, easy to develop / use.
  • Disadvantage:
    1. The same user profile copied many times, can not manage them(in the case you change your profile in 1 gridservice, it does not affect other grids)
    2. User have to remember too many password(even though you can always use the same)
    3. If your name has been taken, you have to change to another - no name portability
    4. other bad points ...

[edit] Use a central OpenID provider

Just like in the web world, there are already lots of website enabled both legacy login and openid login,

UserServer can also support OpenID login, in this case, authentication can be delegated to OpenID providers.

  • Advantages:
    1. User auth information is stored only in 1 place.
    2. no worry about your favorite name has been take.
    3. ... some other OpenID advantages

[edit] UserServer acts as both RP(Relying Party) and OP(OpenID Provider)

UserServer can not only delegate an authentication to another UserServer, but also accept an incoming authtication request from another UserServer.

That means,

  • If a local user login to an UserServer, the UserServer use legacy way(password checking) to confirm the user's identity,
  • If a foregin user login to an UserServer, UserServer delegates the authtication.
  • When an authtication request comes, UserServer checks the user's identity, if OK, UserServer returns the user profile(include name, uuid, inventoryurl, asseturl).


  • Advantages
    1. User auth information is stored only in 1 place.
    2. no worry about your favorite name has been take.
    3. ... some other OpenID advantages
    4. UserServer supports "UserAssetUrl", "UserInventoryUrl", "UUID" by standard
    5. Help the OpenID expansion, minor
  • Disadvantages
    1. More changes needed
    2. Current OpenSim's httpserver is not fully functional(environment variable supports, module supports, compared with apache)

[edit] FOAF+SSL

You should consider FOAF+SSL for this:

http://esw.w3.org/topic/foaf+ssl

A FOAF is a standardised way to provide a global avatar / profile. It also can easily link to other data files.

SSL can be used for security and access control, where necessary.

This is a relatively new technology, but should meet all the long term needs discussed above. However, it is backwards compatible with OpenID, so if you choose to go down that route you can test out a passwordless experience.

Also given the richness and extensibilty of FOAF, it is relatively easy to build applications on top of your FOAF, such as an economy and currency system, web bases social networks and external activity streams.

Retrieved from "http://opensimulator.org/index.php?title=OpenID_for_data_portability_in_virtual_world&oldid=28346"
Personal tools
General
About This Wiki