Glacier Filtering

StuartA

Problem: Using glacier filtering to control user access to individual
methods of an object. (User restrictions can dynamically change)

First attempt:-

interface AssignmentAttempt
{
   // must be student, administrator or marker
   nonmutating float getMark() throws ...

   // must be administrator
   idempotent void setMarker( string markerID ) throws ...

   // must be marker
   idempotent void setMark( float mark ) throws ...
   ...
};

For security purposes, is it better to split this into separate
interfaces ( student, marker, administrator, and a private one ),
where the identity's category matches the userid? ( p715 ). Or is
there some way for glacier to add the userid to the context upon a
remote call? This would allow a servant to do something like:-

... getMark( ... ) const {
   // readlock	   	   
   // get userid from context
   if ( uid != myStudent && uid != myAdmin && uid != myMarker ) {
      // throw some exception
   }     
   return myMark;
}

Or is there a better approach? ( Connection manager that holds userid? )

Thanks,
Stuart

marc

There is currently no way for Glacier to add the user id to the context. However, this seems like a good idea, we will consider adding this to a future version.

One way to solve this is to have a "contract object" (which you can create and destroy along with a session object, or make the session object itself the contract object), and then to not call the server directly, but instead over contract objects.

Depending on the user id and associated permissions, you should have different contract objects, with different interfaces. The category of a contract object should then always be the user id, and Glacier should be configured to filter every category other than the user id.

This is basically the facade pattern, i.e., a facade which hides the server implementation, and gives different clients different interfaces to the back-end. The advantage of this is that you decouple contract from implementation, and have a solid security solution, which nicely integrates with the Glacier session mechanism. The disadvantage is additional complexity.

StuartA

Thanks Marc

Seems like a solid solution. I have one implementation question:

Assumptions ( may be incorrect ) -

1. The config for glacierstarter only takes one
Glacier.Router.SessionManager property ( hence supports only one
session manager ) ?

2. the call `router->createSession()' doesn't pass a context obj
to my session manager ( RouterI.cpp line 129 )

SessionPrx session = _sessionManager->create(_userId);

Question:

If I have only one session manager (MySessionManagerI) , how can a
client send some info to determine which session type (contract) to
instantiate in 'MySessionManagerI::create( .. )'?

Thanks,
Stuart

marc

Originally posted by StuartA

1. The config for glacierstarter only takes one
Glacier.Router.SessionManager property ( hence supports only one
session manager ) ?

If you need several session managers for load balancing, you can put the endpoints of all of them into the proxy for Glacier.Config.SessionManager.

Originally posted by StuartA

2. the call `router->createSession()' doesn't pass a context obj
to my session manager ( RouterI.cpp line 129 )

SessionPrx session = _sessionManager->create(_userId);

Question:

If I have only one session manager (MySessionManagerI) , how can a
client send some info to determine which session type (contract) to
instantiate in 'MySessionManagerI::create( .. )'?

You can use the user ID, and create different contract objects based on the user id.

Alternatively, you can use several glacier starters, with different session managers. For example, you can have one for regular users, and one for administrators.

StuartA

Thanks,

Think I will use the userIds. Tack some info on the front like 'student_u3352933'. This means I will need a custom PermissionsValidator to also rip the contract type off the front ( which I was going to do anyway for LDAP ).

Can't use the username itself because some people are a student and a marker etc.

Thankyou...
Stuart

StuartA

Does AMI effect glacier filtering?

Background:

I'm currently implementing a GUI client to my application in QT
using AMI for remote invocations. If I use a standard (blocking)
invocation, I have no issues. When I use AMI, i get:-

warning: Ice::Exception raised by AMI callback:
OutgoingAsync.cpp:74: Ice::ObjectNotExistException:
object does not exist
identity: S_u3352933/3D76A55E-777B-4693-97F8-720C24749374
facet: 
operation: setCourse

here is the glacier config:

Glacier.Router.Endpoints=default
Glacier.Router.SessionManager=SavviGSessionManager:tcp -p 10000:ssl -p 10001

Glacier.Router.Client.Endpoints=tcp:udp:ssl
Glacier.Router.Trace.Client=2
Glacier.Router.Trace.RoutingTable=2

Glacier.Starter.PermissionsVerifier=PermissionsVerifier:tcp -p 10000:ssl -p 10001
Glacier.Starter.AddUserToAllowCategories=1
Glacier.Starter.Endpoints=ssl -p 11001
Glacier.Starter.PropertiesOverride=Ice.ServerIdleTime=600

I have implemented other AMInvocations, in QT apps without glacier,
and have had no issues.

Your help will be much appreciated
Stuart

PS could you consider changing the minimum search term length for
vBulletin to 3 so searches for AMI, AMD, SSL ... are possible

marc

AMI does not have any impact on Glacier filtering, or on the behavior of an Ice server in general. AMI is a client-side feature only, and is transparent to servers.

StuartA

I'm still struggling over AMI + Glacier.

If I 'ice_ping()', the contract object before an AMInvocation,
everything is fine.

I've attached a modified Glacier demo that reproduces my problem.

Debian Sid - 2.4.17 kernel.
gcc (GCC) 3.3.2 20030908 (Debian prerelease)
Ice-1.3.0

Thanks
Stuart

mes

Stuart,

Thanks for the sample code, we'll investigate this issue.

- Mark

mes

Stuart,

This is a bug in Ice, and it will be fixed in the next release. Meanwhile, you should call ice_ping on any routed proxy before you use AMI.

Thanks again,
- Mark