Glacier2 and ACL aproach

[xdm]

Hello again
I want to implement and object access policy based on ACL objects and combinate it with glacier2 session managament. I want that after a session dispatch a request to an object in retrive the AclProxy associated with the object and invoke the auth method in the AclProxy in order to decide if the resquest is allowed to this user the auth operation must be to params that are the operation name that is invoke and the userId thats send the request. if auth return true the request is dispathched normaly and in other case and AccessDeniedException is throw to client. can this problem addressed extending Glacier2 or in a more simple way

thanks for all and congratulations for Ice a realy great product

[matthew]

Originally Posted by xdm

Hello again
I want to implement and object access policy based on ACL objects and combinate it with glacier2 session managament. I want that after a session dispatch a request to an object in retrive the AclProxy associated with the object and invoke the auth method in the AclProxy in order to decide if the resquest is allowed to this user the auth operation must be to params that are the operation name that is invoke and the userId thats send the request. if auth return true the request is dispathched normaly and in other case and AccessDeniedException is throw to client. can this problem addressed extending Glacier2 or in a more simple way

thanks for all and congratulations for Ice a realy great product

This isn't possible with Glacier2. A typical strategy to implement this is to introduce a facade object that all client->server transactions go through. When the session is initially established the access list can be setup and then the facade can then validate all calls onto the backend.

This allows much more flexibility and protection than simple access control lists. Method parameters can be validated. More protection from denial of service attacks can be provided. Interfaces more representative of the actual business-logic that clients wish to perform can be exposed via the facade.

Regards, Matthew

[xdm]

Hi Matthew

I'm not sure of understand well the method that you are describing how can i do that all request go through the facade object .

for example in my actual aplication when client make a request over a proxy, i have no control of this operation until the request arrive at the corresponding servant.

What you trying say me is that my client must invoke operations over a facade proxy and this make the request to the object proxy? in theese way i think that a lot of extra code is needed or are you thinking in a simple way of doing the same?

thanks for all

[michi]

No, no extra code is needed on the client side. Simply implement the server using a default servant. The default servant can extract the object identity, match it against the ACL, and then forward the actual operation to the "real" servant if the operation is permitted. That way, the existence of the facade object is completely transparent to the client.

Cheers,

Michi.

[xdm]

thanks michi i now understand what you and mathew says. I using a Freeze::evictor as my servant locator because all my busniss objects are persistents using Freeze. if i understand well the Ice RunTime . when a request arrive to the adapter it call locate on the Locator that match with the current.id.category that in my case is a FreezeEvictor and the the FreezeEvictor takes responsavility of restoring the object fron the FreezeDB if needed and add it to the servant active map and dispatch the request to corresponding servant. I wan to continue with use Freeze as my persistence engine. in this case i think that what i need is creating my custom implementation of FreezeEvictor and add here the stuf to check Acl objects.
is this correct aproach?

and other cuestion about this is can a custom locator trows an AuthDeniedExcetion to client in any way or i can only throws IceObjectNotExist

[michi]

Originally Posted by xdm

I wan to continue with use Freeze as my persistence engine. in this case i think that what i need is creating my custom implementation of FreezeEvictor and add here the stuf to check Acl objects.
is this correct aproach?

Yes, that's the way to go about it.

and other cuestion about this is can a custom locator trows an AuthDeniedExcetion to client in any way or i can only throws IceObjectNotExist

Anything other than ObjectNotExistException, FacetNotExistException, and OperationNotExistException that you throw from the locator's locate() method will arrive at the client as UnknownLocalException. However, you can still do what you want: instead of throwing directly from locate(), instantiate a dedicated servant that throws AuthDeniedException from every operation. Then, if you determine inside locate() that access should be denied, return that servant from locate(). The Ice run time then dispatches the call to that servant, which immediately throws the exception.

Because locate() actually returns a servant in this case, this makes the marshaling knowledge available to the run time that is needed to return AuthDeniedException to the client, so the exception won't be translated into UnknownLocalException.

Cheers,

Michi.