[
https://issues.apache.org/jira/browse/OPENEJB-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Louis MONTEIRO closed OPENEJB-473.
---------------------------------------
Resolution: Unresolved
2.x code base no more supported
> Selection of transport does not reflect results of negotiation of css/tss
> properties
> ------------------------------------------------------------------------------------
>
> Key: OPENEJB-473
> URL: https://issues.apache.org/jira/browse/OPENEJB-473
> Project: OpenEJB
> Issue Type: Bug
> Components: corba
> Affects Versions: 2.3-unreleased
> Reporter: David Jencks
>
> I'm pretty sure there's a hidden problem in the client side connection setup.
> We haven't seen it yet because no one has tried a compound security mech
> list with more than one element.
> The ClientSecurityInterceptor looks at all the tss choices and all the css
> choices and picks the best match. Therefore the transport should adhere to
> the transport_mech in this chosen compound security mech config. However,
> the SocketFactory constructs the connection based on the first compound
> security mech in the IOR from the target. This might not be compatible with
> the clients capabilities.
> Here's a hypothetical example:
> tss (server) will accept SSL + client auth and no AS transport info OR SSL
> without client auth and UP AS transport info. It prefers the SSL + client
> auth.
> css (client) will only provide SSL without client auth but with UP AS (This
> means it doesn't have a client cert but does have a user/pw that the server
> will recognize)
> Lets suppose the server is offering these choices on different ports.
> Currently the ClientSecurityInterceptor will choose the second CSM from the
> tss info but the SocketFactory will attempt to connect with the first one,
> which will fail since the server socket will be configured with requires
> client auth which isn't available.
> I think we need some way to communicate the ClientSecurityInterceptors'
> choice to the SocketFactory.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
