[omniORB] omni interceptors

[Sai-Lai Lo]

In the case of passing around a security token, I think the best approach is
to use interceptors to insert and extract the token as service contexts.
Service contexts are part of a well-formed GIOP message. At the moment, the
interceptors in omniORB4 does not allow the application to reject a call. I
think this is a feature worth adding.

As for fully encrypting the bytes sent on the wire, I suggest implement this
as a transport.
There is (or will be) a well-defined interface to hook-up a transport at
runtime. No need to recompile omniORB4 of course. There are other details,
such as how to insert the bit of info into an IOR so that the client knows
when to use your "special" transport, etc. These can also be done via
interceptors.

Having said that, I wonder if there is a need for such a special transport
when SSL seems to fit the bill quite well. On the other hand, one may opt
for using SSL purely for privacy on the wire and use a separate scheme to do
authentication, using security tokens for instance.

Sai-Lai

----- Original Message -----
From: "Renzo Tomaselli" <renzo.tomaselli@tecnotp.it>
To: "Omniorb list" <omniorb-list@uk.research.att.com>
Sent: Wednesday, July 25, 2001 3:51 PM
Subject: Re: [omniORB] omni interceptors


> Sai-Lai,
>  I'm interested in this subject too and for the same reasons, e.g.
> encryption/decryption in a way that concerned IDL models should be unaware
> of. This means both replacing message contents for privacy protection or
> just appending a GSS token for authentication/integrity reasons. The
> opposite should occur at receiver side, with a possibly silent (e.g.
> implementation-unaware) deny of service because of security motivations.
> Things could be even more complex in case of multistage authentication
> procotols, e.i. a challenge/response sequence.
> >From your message I presume that just appending a token might be
fulfilled
> by interceptors, but not full message encryption.
>
> >If you want to do this, a better approach would be to implement it as a
> >transport, similar to the ssl transport. The transport interface in
omniORB
> >4 is much simpler than in omniORB 3. You may want to look into
> ><omniORB4>/src/lib/omniORB/orbcore/ssl/ to see what needs to be done...
>
> Does such transport fit anything like a runtime plugin (e.g. through
> registered callbacks) or does it need to be built into a special version
of
> OmniORB 4 |:-( ?
> Cheers,
>                                              Renzo Tomaselli
> --------------------------------------------------------------------------
-
> TecnoTP s.n.c. Special Information System Design
> Maso Pelauchi I38050 Ronchi Valsugana,  Trento TN  ITALY
> Tel. +39 0461 773164      Fax. +39 0461 771514
> e-mail: renzo.tomaselli@tecnotp.it
> --------------------------------------------------------------------------
-
>
>
>
>
>