[omniORB] Publish object ref only to specified giops

[Konstantin Olkhovskiy]

Hello.
Is it possible to publish some object references to specified giop?
For example, i have ObjectA and ObjectB and server is listening on ssl
and unix sockets, and i want to publish ObjectA both to ssl and unix
but ObjectB must be acces only using unix.

--
Cheers,
Konstantin Olkhovskiy

[Duncan Grisby]

Post by Konstantin Olkhovskiy
Is it possible to publish some object references to specified giop?
For example, i have ObjectA and ObjectB and server is listening on ssl
and unix sockets, and i want to publish ObjectA both to ssl and unix
but ObjectB must be acces only using unix.

There's no way to ask omniORB itself to do it, but you can write code
that directly manipulates IORs to have that effect. For inspiration,
there is some C++ code that messes with IORs in the omniORB connection
management extension in
src/lib/omniORB/connections/omniConnectionMgmt.cc in the
makeRestrictedReference function.

If you're using Python, you can access the innards of object references
by marshalling the reference into a buffer with cdrMarshal, then
unmarshalling it again using the IDL definitions for IORs. I've attached
the IDL you need and some simple code I had to hand that digs into an
IOR. You should be able to use it as the basis for something that
modifies the IORs as you require. After modification, you can do the
cdrMarshal / cdrUnmarshal in reverse to turn it back into an object
reference.

Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ior.idl
Type: text/x-idl
Size: 6089 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100601/dc6af86e/ior.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iorread.py
Type: text/x-python
Size: 1238 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100601/dc6af86e/iorread.py

[Konstantin Olkhovskiy]

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...
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. Also we could use different CA certificates there.
Will this do the trick without killing corba usability?

Post by Duncan Grisby

Post by Konstantin Olkhovskiy
Is it possible to publish some object references to specified giop?
For example, i have ObjectA and ObjectB and server is listening on ssl
and unix sockets, and i want to publish ObjectA both to ssl and unix
but ObjectB must be acces only using unix.

There's no way to ask omniORB itself to do it, but you can write code
that directly manipulates IORs to have that effect. For inspiration,
there is some C++ code that messes with IORs in the omniORB connection
management extension in
src/lib/omniORB/connections/omniConnectionMgmt.cc in the
makeRestrictedReference function.
If you're using Python, you can access the innards of object references
by marshalling the reference into a buffer with cdrMarshal, then
unmarshalling it again using the IDL definitions for IORs. I've attached
the IDL you need and some simple code I had to hand that digs into an
IOR. You should be able to use it as the basis for something that
modifies the IORs as you require. After modification, you can do the
cdrMarshal / cdrUnmarshal in reverse to turn it back into an object
reference.
Cheers,
Duncan.
--
?-- Duncan Grisby ? ? ? ? --
? -- http://www.grisby.org --

[Duncan Grisby]

Post by Konstantin Olkhovskiy
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.

Post by Konstantin Olkhovskiy
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.)

Post by Konstantin Olkhovskiy
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.

[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?

Post by Duncan Grisby

Post by Konstantin Olkhovskiy
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.

Post by Konstantin Olkhovskiy
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.)

Post by Konstantin Olkhovskiy
?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 ? ? ? ? --
? -- http://www.grisby.org --