OpenID for data portability in virtual world

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
(UserServer acts as both RP(Relying Party) and OP(OpenID Provider))
m (Robot: Cosmetic changes)
 
(14 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:
  
Line 18: Line 38:
 
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 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:
+
* Advantages:
 
*# Quick, direct solution, easy to develop / use.
 
*# Quick, direct solution, easy to develop / use.
  
*Disadvantage:
+
* 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)
 
*# 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)
 
*# User have to remember too many password(even though you can always use the same)
Line 30: Line 50:
  
 
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 39: Line 59:
 
*# ... 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. as far as I searched,
+
*** 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,
 
***# 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.
Line 55: Line 75:
  
 
That means,
 
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 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.
+
* 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
+
** user input its OpenID url(probably its Grid's UserServer url), then follow the OpenID authentication protocol -> [[Yadis for UGAI services discovery]]
authentication protocol
+
* When an authtication request comes, UserServer checks the user's identity, if OK, UserServer returns the user profile(include name, uuid, inventoryurl, asseturl).
*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.
  
*Advantages
+
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.
*#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
+
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.
*#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.
+

Latest revision as of 20:42, 3 March 2012


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.

Personal tools
General
About This Wiki