Glacier2 Questions (couldn't find answers in manual)

Wayetender

After testing out Glacier2, I had some questions, primarily dealing with Object Access.

Can glacier2 programatically give a specific user access rights to specific objects? For example:

I have two users. One user should only be allowed access to objects associated with the category "cat1" and their individual object just for that user (Property AddUserToAllowCategories=2). The next user should only be allowed access to objects associated with the category "cat2" and their individual object just for the user. The permissions verifier (or the session server) will distinguish user 1 from user 2 from their username and password and then only give them access to specific categories based on the category-to-user mapping (this should all be done in the program)

The only way I could see doing it was for each server to have a seperate glacier2 instance and configuration, which didn't appeal to me. Please tell me if anything exists to do this, or if it is scheduled to be added (if so an ETA on the release of it)

The next questions is, is there any way to disable the error messages (like the ConnectionClosed Exception messages) on the glacier2 output, or to log them to a logfile?

If those two things can be resolved, I think I'll be totally done with my application's network needs, so thanks so much for your hard work -- it has really helped me!

mes

Hi,

Can glacier2 programatically give a specific user access rights to specific objects?

No, Glacier2 doesn't provide any hooks that would allow you to do this programmatically. The supported mechanism is to set AddUserToAllowCategories to 1 or 2, and ensure that each user is only given proxies whose identities contain the appropriate category. Out of curiosity, why isn't this mechanism suitable for you?

is there any way to disable the error messages (like the ConnectionClosed Exception messages) on the glacier2 output, or to log them to a logfile?

Glacier2 doesn't emit trace messages unless it is configured to do so. Are you sure you are not enabling tracing in the router? If you're still having trouble, please post a sample of these log messages, as well as your Glacier2 configuration properties.

It is also possible to route log messages elsewhere, such as to syslog (Unix), the Windows event log, or to a file. The relevant properties are Ice.UseSyslog, Ice.UseEventLog, Ice.StdOut, and Ice.StdErr.

Hope that helps,
- Mark

marc

As for your first question, you typically do this with a facade. The facade object (which can be the same as the session object, or it can be instantiated by the session object) must have the user id as category, and forward requests to the backend objects, which then can have any category. In other words, the facade provides the user-id to category mapping. Glacier makes sure that only authorized users can call the facade object, but the facade object sets the rules for what set of objects the user can access.

If you have a complex back-end, then the facade also provides you with a clean contract between your client and your server. You can change the interfaces of the back-end objects without having to change the interface of the facade.

As for your second question, Glacier2 doesn't print anything unless you configure it to do so. Most likely you have set Ice.Warn.Connections=1 in your Glacier2 configuration file. Set this property to 0, and you won't see such warnings.

Wayetender

** EDIT: marc answered my previous question **

mes wrote:

Glacier2 doesn't emit trace messages unless it is configured to do so. Are you sure you are not enabling tracing in the router? If you're still having trouble, please post a sample of these log messages, as well as your Glacier2 configuration properties.

Ice.Trace.Network=0
Ice.Trace.Protocol=0
Ice.Warn.Connections=0
Thats the relevant part of my config file for that, anything i'm missing that is default to 1?

mes wrote:

It is also possible to route log messages elsewhere, such as to syslog (Unix), the Windows event log, or to a file. The relevant properties are Ice.UseSyslog, Ice.UseEventLog, Ice.StdOut, and Ice.StdErr.

Ah OK, thank you very much for that. I forgot about that.

Wayetender

I resolved the Glacier2 output problem I was having.

marc wrote:

The facade object (which can be the same as the session object, or it can be instantiated by the session object) must have the user id as category, and forward requests to the backend objects, which then can have any category.

Great, I got that and it works really well. I'm wondering about splitting up my server so I can distribute load. The way I was thinking about doing this is having private Object Adapters run on the private network, then the facade would send the specific object proxy, so the backend could talk with the client directly. Will Glacier be able to forward the clients operations to the private object adapters?

	public override AdministrationPrx getAdmin(Ice.Current __current)
	{
		return AdministrationPrxHelper.checkedCast(__current.adapter.addWithUUID(new AdminI()));
	}

But I was thinking something like this:

Ice.ObjectPrx basePrx;
...
Ice.Properties properties = communicator.getProperties();
        string proxyProperty = "Administration.proxy";
        string proxy = properties.getProperty(proxyProperty); //endpoints on the private network
        basePrx = communicator.stringToProxy(proxy);
...
public override AdministrationPrx getAdmin(Ice.Current __current)
{
        
       return AdministrationPrxHelper.checkCast(basePrx);
}

I tried this, but it didn't work, so is there any other way?
I guess I could forward every message manually from the private object adapter.

..Sorry for all the questions, usually I try to refer to the manual but these final tweaks I'm trying to do don't seem to be anywhere. This problem isn't a huge deal but it would be really nice if I could split up the objects so they run on a completely different server. So the session server would basically only return proxies to the objects on different servers. Anyhow, thanks for your support.

benoit

Glacier2 can forward requests to any objects in the private network as long as it's configured to allow invocation on them. Access to objects on the private network is controlled with the identity categories of your objects and the Glacier2.AllowCategories and Glacier2.AddUserToAllowCategories properties (check out the documentation for more details on these!).

So, if for example you want to allow clients to access any objects whose identity category is "Admin", you'll have to register your admin servants with:

    Ice.Identity id = new Ice.Identity();
    id.name = Ice.Util.generateUUID();
    id.category = "Admin";
    adapter.add(new AdminI(), id);

and set the following property in the Glacier2 configuration:

   Glacier2.AllowCategories=Admin

If this doesn't work or answer your question, you should provide more information and try to add tracing to try to figure out why Glacier2 would be rejecting the requests (if that's actually what happens ). You can bump the Glacier2 tracing with the following properties:

Glacier2.Client.Trace.Reject=1
Glacier2.Client.Trace.Request=1

Hope this helps!

Benoit.

Wayetender

Wouldn't this defeat the purpose of me using a facade for access control, since other clients can just use that object without going through the facade first?

What I want is to have normally private and inaccessible objects to the client, but the facade will control which client gets access to which object, and the session object (which is the facade) can send the proxies to the client, so the client can communicate with this once-private object.

Looking it over and over, it seems like, to keep it secure, is to have a operation on the session object, which the session object will then forward to the private object, and then the private object will send back the results, and the session will relay those results back to the client. I was just wondering if I could have the backend talk directly with the client, but still be private.

benoit

That's right -- if you want to control access to backend objects on a per object and per client basis, you need to implement this control in the facade.

You can add a method to your session interface and have this method forward the request to the backend object as you suggest. You could also create a facade object for your backend object if this backend object has several methods that can be invoked by the client.

If you want this facade object to have the same interface as the back end object you could also use a blobject servant to easily forward all the requests to your backend object (see the Ice manual for more informations on blobjects). However, depending on the complexity of your application, it might be better to have a different interface for the facade object: an interface easier to use and which would mask the complexity of the backend application.

Benoit.