Archived

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

Glacier2 Per Session Context

On this post
http://www.zeroc.com/forums/help-center/3190-per-session-context.html#post14034
you suggest to add context information from the client side, in this case client can spoof identity calling methods with another userid.

My needs is to add an user id info to all the methods callled from the client
but in the the session object to prevent spoofing. Is it possible?

Comments

  • benoit
    benoit Rennes, France
    Hi Paolo,

    Yes, this won't work if you can't trust the client. The best way to achieve what you want is to use a session and facade objects for each client. Your client only interacts with these facade objects to access the back-end servers.

    If you do a search with "facade" on the forums you'll find more information about this. I also recommend to take a look at the first issue of the Connection's newsletter.

    Let us know if you need more information!

    Cheers,
    Benoit.
  • Thanks,
    using facade obects is what i'm doing in my current implementation but is quite painfull. An alternative is forwarding SSL context but it is a considerable overhead,,,,
    I'll study Glacier2 sources
  • matthew
    matthew NL, Canada
    If you don't want to use the SSL context information that can be optionally added by the Glacier2 router then there is another alternative worth mentioning -- that is identity delegation.

    The idea here is that Glacier2 connects with the back end servers with SSL using the clients identity. This allows back end servers to uniquely identify the original caller with only the same overhead as regular SSL. However, the bad news is that this is not currently implemented. If you are interested in sponsoring such support please email us at sales@zeroc.com.
  • Following your suggestion I'm now convinced to use the facade approach,
    what I'd like to do is to add a method with this signature to my session interface:

    Object* create_object(string type_id)

    and implement in the backend something like an Object Factory that create objects in the server based on the ice type_id. Is it possible?
    Is there an Ice facility to create Ice Objects based on type_id?
    The only solution I found is to match Ice Type Id with c++ RTTI but It's not a portable approach.
  • What about this solution?

    1) Getting the Object Factory from comunicator with: findObjectFactory(string id)

    2) Creating the object with :
    ObjectFactory.create(string type)

    Is this the right way?
  • benoit
    benoit Rennes, France
    Hi,

    The Ice object factories allow you to instantiate Slice classes or interfaces given their slice ID. Only factories added with addObjectFactory can be retrieved with findObjectFactory of the Ice::Communicator object so you'll need to implement and add a factory to the communicator for each of the servant type you want to instantiate. See the Ice manual for more information.

    For the implementation of your create_object method you can either use the communicator object factories or use your own factory to instantiate new servants. Once your servant is instantiated, you'll then need to register it with an object adapter since you want to return a proxy on an Ice object (see this FAQ for more information on servants, Ice objects, proxies).

    Cheers,
    Benoit.