[Opensim-dev] secure_inventory_server ??
liu xiaolu
lulurun at gmail.com
Sat Jul 26 04:27:34 UTC 2008
Hi good morning,
Personally I'm still far from being sold on a pull system. I think inventory
> and asset servers should be independent. You can set permissions in them to
> say who can access what and what rights they have. But to have a inventory
> server pulling things from various users servers just seems wrong. Its
> making everything too centralised in my opinion.
These my final points:
1. Objectively, once more, inventoryserver contains no information that can
make sure if a request
is or not from a valid user. only userserver contains that information,
and we all do not want
such kind of "identity" information to be copied everywhere.
2. according to 1, no matter push or pull, inventoryserver has to validate
the request or anyone can
use it. => inventoryserver has to "pull" or be "pushed" authed
information from 1 or many
userservers.
3. that doesn't mean inventoryserver has to rely on some userservers,
inventoryserver just rely on
if the user want it to validate and how the user want it to validate
requests. as I said,
inventoryserver exists for its user, not userserver, why inventoryserver
have to "pull" or be
"pushed" something is because "users" *want* do that to save their
inventory. inventoryserver
works for users, it does not always trust 1 or some userservers, it
trusts what the user specified.
It acts as what the user want it to do.
X. authenticated information such like session_id, has the same security
level with password, even
the current "pull" does not really pull "session_id", it only "pulls"
true or false.
Y. "push" has security issue that any remote peer can "push" to
inventoryserver. to set access
permissions on inventoryserver side or make a "safe peers" list ?
I think the "permission" should not be "user" based, because it is
unsafe either, then if the
"permission" is "url" based, doesn't that mean the same as
inventoryserver rely on the
"safe peers" ?
But having said that, if we could at least get a pull system that works and
> doesn't break use cases then thats great. But at the moment the current
> system does break perfectly valid use cases.
>
Really, I think "push" is much more dangerous, and "pull" does not have to
be designed "rigid".
if you can take time to write some of the usecases that should be support,
but current "pull"
inventory breaks them, I would like to do what ever I can do to think and
implement.
regards,
lulurun
>
>
> *liu xiaolu <lulurun at gmail.com>* wrote:
>
> After all, please understand that I am not "selling" how my "secure
> inventory" is great,
> I made it because I found my interop module is an ease-to-use tool to
> modify others' inventory(at OSGrid.org).
> if there are bugs or broken things please let me know.
> hope it is fixed or I would like to offer what I can do to help the fix.
> What I am trying to do is to share my point of view on "interop", that is
> what I called avatar portability.
> maybe I replied to a wrong mail.
>
> So, about the usecase: (I finanlly got your idea, from the quoted mail)
> >The use case (or one of many) that I'm talking about, is if a user has
> inventory on a inventory server, that user's inventory shouldn't be tied to
> any user server/grid. So the user should be able to use the same inventory
> set on multiple grids. At the
> >moment that means they have the same userid on each grid but thats no
> problem (and in the future I hope we will support a better way of
> identifying a inventory belongs to a user).
> >
> >So lets call the Inventory server InvN like you used. My single inventory
> set (of folders/items) on that server is called InvSetA. Then we have Grid A
> and Grid B. With user server A and B. When I log into grid A it should use
> InvN to receive InvSetA.
> >But also if I log out of grid A and log into grid B then it should also
> use InvN to receive InvSetA. The inventory set (of folders/items) isn't tied
> to a single grid/avatar. It belongs to the user. The "grid" is just using a
> guid (avatarID) to access the correct
> >inventory set. So as long as both grids use the same id, they should be
> able to use the same inventory.
> When I read the above sentences, what I was thinking is "why it is required
> to be like such a case?"
> Still, There are 3 situations I can imagine:
> *1*. UserA and UserB do not know each other, by (small) chance, thier UUID
> are the same.
> uuid collision, hard to say anything.
> yes, we do should care about this, though I learned that uuid
> wouldnot duplicate in common life, but we cannot trust the implementations.
> I think this is possibly not what you mean, even if you really mean
> this ...
> the "userserver_dictionary" should be "uuid at grid_identifier",
> "userserver_url", grid_identifier can be the address(host,ip) of the grid
> service, hmmm ...
> *2*. UserA and UserB are the same person.
> In order to login to both GridA and GridB, an User copied his/her
> account both at GridA(UserA) and GridB(UserB), so they are having the same
> uuid.
> I suggest to use the way I mentioned: he/she can always keep one
> account at GridA, and travel to both GridA and GridB.
> reasons for the suggestion:
> 1. coping account is not a forever solution for grid-grid travel.
> 2. there is an advanced way, we should encourage ourself to use that
> *3*. UserA and UserB are completly different accounts, they are
> friends/groupmember(or they are owned by the same person who intend to do
> such thing),
> they want to share InvSetA(both of them can CRUD InvSetA)
> InvSetA only can be specified by user uuid, so they *have* to have
> the same uuid to share InvSetA,
> this can be solved in another level - inventory does not belongs to a
> user, it belongs to a group.
> * a group has 1 uuid used to identify inventory
> * a group contains mutilple/single user
> this may introduce "join" SQL statements to "select" the inventory,
> instead of just "select" by "uuid". ... no deeper thoughts.
>
> I want it be a "pulling" system, because
> * "push" has security issues, session_id or what ever things that is used
> as a secret to prove identity, shouldn't be "pushed" to everywhere
> * I still do not think the case you are concerning is a major case, or even
> I think it is strange, except you are meaning *3*. but *3* is another issue.
> * "pulling" reduces the responsibility of inventoryserver, in the case,
> inventoryserver couldn't get auth infomation for the specified userserver,
> because userserver
> is specified by user itself, so it the problem of the user, not the
> inventory, but "push" is the opposite, to think inventory/asset server will
> play a important roll
> in the future, the less responssibility it has the more it is reliable.
>
> Wrote too much english today ... see you tomorrow
> thank you for your detailed explanations.
>
> regards,
> lulurun
>
> 2008/7/26 Michael Wright <michaelwri22 at yahoo.co.uk>:
>
>> I might be missing something but I don't see how this solution addresses
>> some of the problems. Maybe I wasn't very clear on some of the use cases
>> that would currently be broke.
>>
>> The use case (or one of many) that I'm talking about, is if a user has
>> inventory on a inventory server, that user's inventory shouldn't be tied to
>> any user server/grid. So the user should be able to use the same inventory
>> set on multiple grids. At the moment that means they have the same userid on
>> each grid but thats no problem (and in the future I hope we will support a
>> better way of identifying a inventory belongs to a user).
>>
>> So lets call the Inventory server InvN like you used. My single inventory
>> set (of folders/items) on that server is called InvSetA. Then we have Grid A
>> and Grid B. With user server A and B. When I log into grid A it should use
>> InvN to receive InvSetA. But also if I log out of grid A and log into grid B
>> then it should also use InvN to receive InvSetA. The inventory set (of
>> folders/items) isn't tied to a single grid/avatar. It belongs to the user.
>> The "grid" is just using a guid (avatarID) to access the correct inventory
>> set. So as long as both grids use the same id, they should be able to use
>> the same inventory.
>>
>> So in this case if we have the pull from user server approach to
>> authenticating then it needs to switch between user server A and B,
>> depending on what grid the user is currently logged into. So again it would
>> require a push somewhere to update which is the current user server for that
>> user.
>>
>> As far as I can tell, your solution just stops a inventory server being
>> tied to a single grid/user server and instead ties each inventory set to a
>> grid/user server. That is better than tying the whole server. But it doesn't
>> support the above case.
>>
>> There are a number of other use cases that would require multiple
>> grids/instances to access a single inventory set.
>>
>> I find it helps if we think of User server and the grid server as seperate
>> to the inventory and asset server. The user server defines what users can
>> access a grid (plus other data like what inventory server that user is
>> using). The grid server defines and manages what regions are on a grid.
>>
>> But asset and inventory server can (in part) be thought of more as end
>> user servers. In that a user could use the same servers on multiple grids
>> and that can mean using the same inventory on all grids. So then if we think
>> about defining on the asset and inventory servers what grids/regions can
>> access them.
>>
>>
>> *liu xiaolu <lulurun at gmail.com>* wrote:
>>
>> First, I want to clarify that, I am not against what you said
>> To release inventory, asset server become independent ones is also what I
>> have been working on.
>>
>> I am just trying to introduce my thoughts:
>> >>[solution:]
>> >>* add a new table for inventoryserver, 2 fields, useruuid,
>> userserver_url, everytime inventoryserver
>> >> extract "session_id", "user_id" from the request, get "userserver_url"
>> by "user_id", then check the
>> >> identity of "user_id" from "userserver_url" (call check_auth_session)
>> >I really think rather than the inventory server calling a authenticate
>> method on the user server. That
>> >the user server should send a sessionid to the inventory server when a
>> new login happens. I guess
>> >your idea of the userserver_url was something silmilar in that the
>> userserver would update it when
>> >a user logs in? Otherwise if it was just "hardcoded" in the db then it
>> wouldn't solve anything.
>>
>> sorry for the lack of explanation of the new table, temporary let me call
>> it "userserver_dictionary".
>> * "userserver_dictionary" is a table always together with inventoryfolers,
>> inventoryitems
>> * "userserver_dictionary" has 2 column: user_id pkey, userserver_url
>> // user registration
>> when a new user registered at a GridService G1, the user will possibly
>> have its account on G1's
>> userserver U1, then, no matter which inventoryserver the user is using(or
>> going to use), assume it is called InvN,
>> InvN's "userserver_dictionary" would be added 1 record <"uid", U1's url>,
>> // user login to VW
>> * user get authentication at U1, get "session_id"
>> * user login into a regionserver, regionserver gets user's profile and
>> extract user's inventoryserver InvN from its profile.
>> * regionserver requests getInventory("session_id", user.uuid) from InvN.
>> * InvN gets "U1's url" by user.uuid from "userserver_dictionary"
>> * InvN requests check_auth_session("session_id", user.uuid) from "U1's
>> url"
>> //
>> in this case, dose InvN satisfies what you want ?
>> * InvN is separate from any other server
>> * InvN is independent, not rely on any userserver, it pull identity under
>> user's specification(get "userserver_url" by uuid)
>> * InvN can store users from different gridsevices
>>
>> --
>> Lulurun
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>> ------------------------------
>> Not happy with your email address?
>> Get the one you really want <http://uk.docs.yahoo.com/ymail/new.html> -
>> millions of new email addresses available now at Yahoo!<http://uk.docs.yahoo.com/ymail/new.html>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
>
> --
> Lulurun
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> ------------------------------
> Not happy with your email address?
> Get the one you really want <http://uk.docs.yahoo.com/ymail/new.html> -
> millions of new email addresses available now at Yahoo!<http://uk.docs.yahoo.com/ymail/new.html>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
--
Lulurun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080726/6c2bd9f3/attachment-0001.html>
More information about the Opensim-dev
mailing list