Callbacks in an CORBA-SSL-only environment

--===============0715194753186995369==
Content-Type: multipart/alternative; boundary="000000000000cdc5a40651871cfa"

--000000000000cdc5a40651871cfa
Content-Type: text/plain; charset="UTF-8"

Hi,

We are currently moving our CORBA server (Based on JacORB) towards an
SSL-only configuration, i.e. we deactivate the regular CORBA port
completely and allow only CORBA SSL (via ssliop). Our clients are based on
OmniORB and we currently try to find an OmniORB configuration that works
both for a CORBA server which supports (a) both plain CORBA and CORBA SSL
and (b) only CORBA-SSL [To clarify: The expectation is, that the client is
connecting via CORBA SSL, but should not know whether the server accepts
either both CORBA SSL and plain CORBA or only CORBA SSL].

During my experiments I stumbled across the following issue when CORBA
callbacks are involved (That is: The OmniORB client registers a callback on
the  JacORB  server).

Originally I had the following set in the OmniORB configuration:

clientTransportRule =     *   ssl,unix,tcp,bidir

serverTransportRule =    *     ssl,unix,tcp,bidir

endPoint = giop:ssl::
               = giop:tcp::

(A) My expectation was that under these client settings of  endPoint
giop:ssl::would be still preferred regardless of the server constraints,
but that doesn't seem to hold. If the server is configured SSL-only, the
client callback waits endlessly and is not called (without producing a
CORBA connection error visible in the omniORB log file even under
traceLevel=40. I found that it is required to set

endPoint = giop:ssl::

to ensure that a client callback is called regardless whether the server is
configured SSL-only or not. Is this behaviour expected and my chosen
configuration the right one? What is the reason for this?

(B) Then I tested the same scenario using unidirectional connection instead
of bidirectional configuration (The POA construction was correspondingly
adjusted programmatically), i.e.

clientTransportRule =     *   ssl,unix,tcp

serverTransportRule =    *     ssl,unix,tcp

endPoint = giop:ssl::

Under these conditions the client callback never becomes called when being
connected to a server configured as SSL-only. I'm wondering now, what kind
of OmniORB setting is required to make callbacks work under such
unidirectional conditions?

Thanks for any hint,

- Daniel

--000000000000cdc5a40651871cfa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>We are currently moving =
our CORBA server (Based on JacORB) towards an SSL-only configuration, i.e. =
we deactivate the regular CORBA port completely and allow only CORBA SSL (v=
ia ssliop). Our clients are based on OmniORB and we currently try to find a=
n OmniORB configuration that works both for a CORBA server which supports (=
a) both plain CORBA and CORBA SSL and (b) only CORBA-SSL [To clarify: The e=
xpectation is, that the client is connecting via CORBA SSL, but should not =
know whether the server accepts either both CORBA SSL and plain CORBA or on=
ly CORBA SSL].</div><div><br></div><div>During my experiments I stumbled ac=
ross the following issue when CORBA callbacks are involved (That is: The Om=
niORB client registers a callback on the=C2=A0
JacORB=C2=A0 server).</div><div><br></div><div>Originally I had the followi=
ng set in the OmniORB configuration:</div><div><br></div><div>clientTranspo=
rtRule =3D =C2=A0 =C2=A0 * =C2=A0 ssl,unix,tcp,bidir</div><div><br></div><d=
iv>serverTransportRule =3D =C2=A0 =C2=A0* =C2=A0 =C2=A0 ssl,unix,tcp,bidir<=
/div><div><br></div><div>endPoint =3D giop:ssl::<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D giop:tcp::</div><div><br></div><div>(=
A) My expectation was that under these client settings of=C2=A0
endPoint=C2=A0 giop:ssl::would be still preferred regardless of the server =
constraints, but that doesn&#39;t seem to hold. If the server is configured=
 SSL-only, the client callback waits endlessly and is not called (without p=
roducing a CORBA connection error visible in the omniORB log file even unde=
r traceLevel=3D40. I found that it is required to set</div><div><br></div><=
div>
<div></div><div>endPoint =3D giop:ssl::</div><div><br></div><div>to ensure =
that a client callback is called regardless whether the server is configure=
d SSL-only or not. Is this behaviour expected and my chosen configuration t=
he right one? What is the reason for this?=C2=A0</div><div><br></div><div>(=
B) Then I tested the same scenario using unidirectional connection instead =
of bidirectional configuration (The POA construction was correspondingly ad=
justed programmatically), i.e.</div><br></div><div>
<div></div><div>clientTransportRule =3D =C2=A0 =C2=A0 * =C2=A0 ssl,unix,tcp=
</div><div><br></div><div>serverTransportRule =3D =C2=A0 =C2=A0* =C2=A0 =C2=
=A0 ssl,unix,tcp</div><div><br></div><div>endPoint =3D giop:ssl::</div><div=
><br></div><div>Under these conditions the client callback never becomes ca=
lled when being connected to a server configured as SSL-only. I&#39;m wonde=
ring now, what kind of OmniORB setting is required to make callbacks work u=
nder such unidirectional conditions?</div><div><br></div><div>Thanks for an=
y hint,</div><div><br></div><div>- Daniel</div><div></div>

<br></div></div>

--000000000000cdc5a40651871cfa--


--===============0715194753186995369==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
omniORB-list mailing list
[email protected]
https://www.omniorb-support.com/mailman/listinfo/omniorb-list

--===============0715194753186995369==--