[ http://issues.apache.org/jira/browse/GERONIMO-1145?page=comments#action_12357112 ]
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 token 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 authentication. 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: http://issues.apache.org/jira/browse/GERONIMO-1145 > 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 connection. > 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
