[omniORB] excluding non-local objects

[Duncan Grisby]

On Monday 15 July, "Renzo Tomaselli" wrote:

>     within an architecture made up of many distributed components I happens
> that some of them MUST be colocated because of security reasons, e.g. they
> should not be capable of being contacted from foreign address spaces.
> Even in such cases we want to retain the same procedure to develop them: UML
> design -> IDL -> OmniIDL -> C++ implementation instead of straight
> publishing a local C++ interface.
> Saying an object is not published in any repository is not enough because we
> all know how to make an IOR once the obj key schema is known or stolen,
> unless it is truely random.

Indeed. The object keys omniORB creates are very predictable. You
could easily use a POA with the USER_ID policy and create your own
cryptographically secure random numbers, though. Of course if you ever
transmit such object references over a network, they can be snooped,
and the snoopers can then contact your object.

> I know about dirty tricks such as using object keys embedding hints such as
> local pointers/keys.

That's one option. Another option is to create some thread specific
data before a call, and check it in the operation implementation.
Threads omniORB uses to do calls from remote clients won't have the
per-thread data, so you can trap them.

> However I wonder if just skipping object registration with its POA is enough
> to prevent this object to be contacted by remote processes while being
> capable of working as a local entity.

You have to be clear about the difference between a servant and a
CORBA object. If you don't register your servant in a POA, there is no
CORBA object corresponding to it, and it can therefore not be
contacted remotely. It can only be contacted locally by a direct call
on the servant, rather than an ORB-mediated call through an object
reference. This defeats most of the point of using CORBA IDL, but it
does mean your servant class is checked for compliance to the
interface by the C++ compiler. If that's all you need, this is a good
approach.

> Another complementary question: is there any mehtod (even OmniORB private)
> to enumerate objects activated by a remote POA ?

No. There's not even any way to enumerate the objects activated by a
local POA.

Cheers,

Duncan.

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