geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <>
Subject [jira] Commented: (GERONIMO-1145) Too many ORBs (or possibly not enough)
Date Wed, 09 Nov 2005 09:28:21 GMT
    [ ] 

David Jencks commented on GERONIMO-1145:

First of all, I don't think CSS info is ever encoded in an IOR, just TSS info.

Let me see if I can make my example more concrete, while changing the names of the participants

A is an app client with a client cert and a user/pw

B is an ejb on an app server b.  B requires a client cert for user authentication, no identity

C is an ejb on an app server c.  C requires either a client cert for server authentication
and an identity token, or a no-client-cert SSL connection with AS level user-password client

A calls a method on B, authenticating the user identity with the client cert. 

The B method calls C, using the b cert to identify the server, and including an identity token
identifying A as the user.  C returns a handle

B returns the C handle to A.

How is A supposed to use the handle?  It has appropriate info (the user/pw) but no way to
negotiate a security policy with C.   Neither the configuration it used to contact B nor the
configuration B used to contact C are usable for A to contact C.  It might be able to use
the CSS info associated with the ejb-ref to B, but there is no way currently to apply it to
the attempt to contact C.   

> Too many ORBs (or possibly not enough)
> --------------------------------------
>          Key: GERONIMO-1145
>          URL:
>      Project: Geronimo
>         Type: Bug
>   Components: OpenEJB
>     Versions: 1.0-M5
>  Environment: All
>     Reporter: Rick McGuire

> This is sort of complicated problem to describe, but there is a problem with the wrong
ORB getting used with remote references passed in with a request.  In the current architecture,
when a CORBA bean is started, it calls Util.setORB() to register itself as the server ORB.
 Util.setORB() ignores all registration calls after the first. so the first CORBABean started
in the server will determine the ORB instance returned by all context.lookup("java:comp/ORB")
calls in the server.  This value is set in StandardServant using:
>         // create ReadOnlyContext
>         Map componentContext = new HashMap(2);
>         componentContext.put("ORB", Util.getORB());
>         componentContext.put("HandleDelegate", new CORBAHandleDelegate());
>         try {
>             enc = new SimpleReadOnlyContext(componentContext);
>         } catch (NamingException e) {
>             throw new RuntimeException(e);
>         }
> which uses the ORB object returned from Util.getORB().  This ORB value is used for a
lot during request processing, particularly when accessing information from remote references
passed to this EBJ.  If there are multiple CORBA beans configured for the server, this can
create connection problems when the beans are configured with different TSSConfigs.  In the
case we ran into, an ORB instance configured for non-secure transports was trying to (correctly)
use an SSL connection to perform an operation.  The connection failed in this case because
the ORB did not have the correct transport-level security configuration needed to make the
> The appropriate solution would be for the StandardServant to set up the comp/ORB value
to be the ORB associated with the owning POA instance (created in the TSSBean). 

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message