[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.ecf] Re: Concerns about this simple chat 
Comments embedded.

Scott Lewis wrote:

Hi John,

John F. Patterson wrote:

I understand that the simple chat outlined here is really more or less a hello world example, but I would like to explore my understanding by rasing some concerns about it.

First, since the ID of the SharedObject is based on a well-known name, i.e., "chat" anyone who has permission to join the server.com container may join the chat. How do we restrict the chat to a limited audience?


In general, there will be many ways that containers could authenticate. The purpose of the 2nd param in the joinGroup(ID,Object) method call is to allow the passing of arbitary information for authentication (so, for example, the Object could be a JAAS LoginContext).

I guess I was asking whether I can restrict access to a SharedObject.

> One approach seems to be to create the chat object with a random name
> and do a sendCreate to those we wish to invite. Does this sound >right?

Even if the random name is truly unguessable, sending a message to an invitee in the clear would be insecure.
The intention of the 'sendCreate' message is really to allow the creation of a remote replica of a given shared object.

This is what I was trying to do. I was adopting the approach that the container is like a large lobby to which many may come and that a chat SharedObject will be created for a conversation within the lobby.

This message could be used to just communicate an ID for a new group, but it would really just be preferable to use sendMessage(remoteInvitee,newGroupID). Then the receiver could respond to this message by creating a new container and joining that container. If the container requires authentication and the invitee has it it can provide it, if it doesn't have it then the invite was not appropriate anyway.

This seems to be an approach that is more like what Li-Te was outlining at the outset. There are multiple ways to achieve a chat and it might help the conversation to keep the approaches straight. I'll try to outline the alternatives (as I see it) in a separate message.


<stuff deleted>


Second, there does not appear to be any way to know who has joined the chat.


No. config.getContext().getGroupMemberIDs() provides the current group membership. Also:

config.getContext().getSharedObjectManager().getSharedObjectIDs()

Does this tell me the set of shared objects that I have created? Or, the set of all SharedObject IDs known to the container whether I am participating in that SharedObject or not? If it is the latter, then my notion of creating chat objects using random IDs might not work very well for privacy, since anyone could get this list and start fishing for chat SharedObjects that they were not invited to.

Also, if it is the full list, how do I know the type of the SharedObject, i.e., the SharedObjectDescription?


provides information about the current shared objects.

This tells you about the set of shared objects, but it does not tell you who has actually created the shared object and is therefore participating in it. Under many uses the SharedObject is like a mini-meeting within the meeting. Often, we will want to know who is participating in that SharedObject.

<stuff deleted>


Third, since the name associated with a chat entry is completely under the control of the user, anyone could contribute to the chat without ever revealing the login name associated with their access to server.com.


This is just the way I chose to implement the nickname functionality in this example. It would probably be more common for each user to have their own 'presence' object...where the ID for the object really is a full user identity. In that case, however, the chat would receive messages from the presence object and use the sender object ID to be
sure that it's who it says it is.

If the 'presence' objects are still constructed by the user, isn't it still an opportunity for spoofing. It seems to me that the provider is the honest broker here. It needs to provide a way to associate the user information (presence object) with the authenticated ID in such a way that it cannot be spoofed. I do not currently see a way to do that in ECF.

Do the messages arrive tagged by the authenticated name of

the sender?


Yes. In the events that are ISharedObjectEvent implementers have a method ISharedObjectEvent.getSenderSharedObjectID(). Both messages from remote replicas (ISharedObjectMessageEvent), and from local 'other' shared objects (ISharedObjectEvent) have access to the 'sender'

Is this the ID of the group member or the ID of an object created by the user for the purpose of exposing identity? The name getSenderSharedObjectID suggests it is the latter. If the user creates the presence object, then what prevents spoofing?

If so, why wouldn't we use that name in the chat transcript?


You could. And for some chats you surely would. Other chats it would not be desired or necessary...it would depend upon the requirements on the chat.

Understood.

[stuff deleted]