[omniORB] Publish object ref only to specified giops

[Konstantin Olkhovskiy]

Given peer credentials in python interceptor i can implement some
decorator-based ACL magic.
My college dislikes possibility for a client to even try to invoke
object he does not have access to. And it sounds reasonable as far as
security concerned. But running two applications on different giops
looks hacky.
Private part of a system is something like 'kernel'. And other parts
must have restricted access to some interfaces of this kernel.
Decorators and interceptors are the only way to do it in a single
application? Is there any other place i can plug in some validation
code and access control management?

2010/6/3 Duncan Grisby <duncan at grisby.org>:
> On Wed, 2010-06-02 at 14:51 +0400, Konstantin Olkhovskiy wrote:
>
>> Purpose of such hacking was security. What stops client from creating
>> IOR by hand and calling object which is not intended to be called from
>> that client? IOR's are not signed or anything...
>
> You definitely can't use an approach of limiting endpoint information in
> IORs for security. As you say, clients can create IORs themselves and
> therefore subvert any scheme you put in place.
>
>> One idea of implementing such a feature is to serve different
>> components from two separated programs using different giop
>> endpoints... If one giop is 'public' and other is 'private' - private
>> part of system can invoke public objects using public giop, but public
>> part of system can't use private part cause private giop is not
>> physically(i.e. unix socket, vpn connection) accessible from public
>> part.
>
> The limitation with that kind of thing is knowing where the client came
> from. It's a violation of the CORBA invocation model to know those kinds
> of connection-level details about a client, so there's no easy way to do
> it. (I certainly think it would be better if CORBA didn't hide the
> transport layer from the application layer so much, but it does, and
> that makes it hard to do anything in that area.)
>
>>  Also we could use different CA certificates there.
>> Will this do the trick without killing corba usability?
>
> You certainly could do that (assuming you are using the SSL transport).
> An interceptor can look at the SSL details and set some per-thread state
> appropriately to identify the clients. You can only do that with a C++
> interceptor, though, since Python does not have access to the OpenSSL
> state.
>
> An easier approach (and one that can be done from Python) is to
> implement your own service context in calls. You can use a
> clientSendRequest interceptor to add your own client details (using
> whatever identity mechanism you feel appropriate), then read them from a
> serverReceiveRequest interceptor. That interceptor can set per-thread
> state so the application code can see client details. That can all be
> done with omniORB's interceptors. It's something I have used myself.
>
> Cheers,
>
> Duncan.
>
> --
>  -- Duncan Grisby         --
>  -- duncan at grisby.org     --
>   -- http://www.grisby.org --
>
>
>



-- 
Cheers,
Konstantin Olkhovskiy