Archived

This forum has been archived. Please start a new discussion on GitHub.

controlled casting (facets?)

I would like to implement a servant that implements multiple interfaces, and only allow certain clients to access certain interfaces. (Basically, I want an administrative interface as well as a "normal-client" interface.)

Conceptually, the admin interface is an extension of the normal-client one, so my first thought was to have a slice definition that was something like:
interface Client {
    string getStatus();
};

interface Admin extends Client {
    void shutdown();
};

My concern with this is that a malicious client could checkedCast (or even uncheckedCast, I guess) from their ClientPrx to an AdminPrx.

My next thought was that I could keep the interfaces separate, and have the servant registered with two identities. I'm still not certain that a malicious client couldn't just cons up a proxy to the Admin and stick it onto the wire, of course, and I worry about hackeruser faking up a proxy to the admin that was returned to superuser, so I turned to the Glacier docs to see if I could mark a proxy as being only for a certain client. I can, it turns out, but I have to make the category match the username. (It'd be a little annoying to also have to wire glacierstarter into my existing authentication system, but I can bear that pain.)

I happen to use Freeze to manage the eviction of these Client servants, though, so I'm a little nervous about what happens if, for example, the Client "view" of the servant is evicted and then we get a request for the Admin "view". And then the Client "view" is revived with a new servant, and ... *worry*. (How is Freeze or evictor management supposed to work with the Glacier username-as-category stuff, anyway?)

I had maybe hoped, at this point, that I could do some sort of access control on the basis of an Ice facet, such that I could hand out a facet with the username's category and keep everything in sync on the Freeze side. Facets are somewhat underdocumented at the moment, though, and I understand that there's some major rearchicture going on in that area.

Anyone have any ideas on how to handle this sort of thing? I'm -- perhaps obviously -- a little lost.

Mike

Comments

  • marc
    marc Florida
    There are two methods I recommend for access control:
    • You can have separate Ice objects for admin and regular use, registered with separate object adapters. The OA for the admin Ice object has SSL endpoints only, and your client must provide a valid certificate in order to access.
    • You can use two Glacier instances, with different kinds of password control. One that restricts access to non-admin Ice servants, and another one that grants access to all servants. (Using the category filtering.)
    In any case, using facets or interface inheritance is not a good idea for access control, because the granularity for OA-based access control or Glacier-based access control is an Ice object, not facets or interfaces of Ice objects.

    I'm not sure I understand your concerns about Freeze. In general, Freeze is transparent: You invoke on Ice objects, and Freeze instantiates and evicts servants for the Ice objects.
  • Ice 2 Follow up

    Have things in the Ice world significantly changed with the introduction of Ice 2 and Glacier 2? I was interested in accomplishing the same security control with facets. I've read about object filtering, but that wouldn't affect the ability to cast once the client has the object.

    At the worst, I was hoping that if the client side code didn't have the admin proxy code that would help. By my guess is dynamic ice still makes that dangerous?

    Thanks,
  • mes
    mes California
    Hi Seth,

    Using dynamic Ice it is possible to invoke any operation on a proxy. Of course, it makes it a lot easier if you know the signature of the operation as well as its data types. In any event, regardless of whether you publicize the operation signatures, if your objects are accessible you should assume that they can be called.

    - Mark