This forum has been archived. Please start a new discussion on GitHub.
I think it would be good if the Ice registry/locator could actually lock out session allocation of objects that have already been allocated; as it stands now, it is necessary that clients respect the semantics of session allocation. My understanding is that anyone can still get an indirect proxy to an object registered with the locator, bypassing the allocation scheme. But, maybe I'm missing something with Glacier...
If the client goes through Glacier2 then IceGrid will automatically adjust the Glacier2 filters to block access to the allocated object once its been released -- so I don't think this is a problem.
If the client doesn't go through Glacier2 then there is little that IceGrid can do. If the client has a direct proxy to the allocated object unless there is some other mechanism in place to stop access (such as SSL + authentication) then the client is free to directly connect and play with the object in question completely bypassing IceGrid.0
The problem here comes from the way our environment works. We have a lot of users who are inside the firewall that protects our laser system, and, for various reasons, all of the workstations in the system have to be within the firewall, so Glacier2 offers no completely enforceable protection against anyone "in the know" about how Ice works.
Additionally, we cannot use SSL to protect objects (please don't ask "why not?", I'll just start ranting). So, the IceGrid allocation mechanism is not as sealed up as I'd like in our environment. We don't really have to protect against malicious attackers, so it's not a total show stopper, but people do make mistakes; it would be nice to not give them the opportunity to screw up....0
Even if the locator didn't return the endpoints of non-allocated indirect object adapters, it would still be possible for a client to contact the server directly if it knows its endpoints. So this wouldn't really add much security to your application.
Doing this would also require more work for client applications as they would need to use a special "session" locator to get access to objects and indirect object adapters which they have allocated.