geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: Using the KeystoreManager for CORBA SSL support
Date Fri, 12 May 2006 15:01:22 GMT
You can't have a single GBean hold all that information and make it
the same for every SSL client/server.  For example, the client needs
no keystore if it's not using client auth, and needs a separate
keystore if it is.  The protocol and algorithm can probably be
configured at the JVM level -- I'm not sure about the rest.  It's
plausible that you might want two different SSL connectors with
different key/trust/client auth settings, one for internal clients and
one for external clients.

Thanks,
    Aaron

On 5/12/06, Rick McGuire <rickmcg@gmail.com> wrote:
> I'm looking at implementing KeystoreManager support in the openejb CORBA
> TLS layer (see Jira GERONIMO-2002), and I'm having trouble deciding how
> best to do this.  The KeystoreManager GBean merely manages access to the
> keystores and the creating of SSLSocket factories for creating
> connections (and currently, it only supports SSLServerSockets, but it's
> a fairly trivial matter to add SSLSocketFactory support too).  In order
> to use the KeystoreManager to create a socket, the caller must provide a
> number of additional pieces of information, such as the truststore and
> keystore names, and the key alias.  For example, here's the
> configuration for the HTTPSConnector used to configure Jetty:
>
>     <gbean name="JettySSLConnector"
> class="org.apache.geronimo.jetty.connector.HTTPSConnector">
>         <attribute name="host">${PlanServerHostname}</attribute>
>         <attribute name="port">${PlanHTTPSPort}</attribute>
>         <attribute name="keyStore">geronimo-default</attribute>
>         <attribute name="keyAlias">geronimo</attribute>
>         <attribute name="trustStore">geronimo-default</attribute>
>         <attribute name="clientAuthRequired">false</attribute>
>         <attribute name="algorithm">Default</attribute>
>         <attribute name="secureProtocol">TLS</attribute>
>         <attribute name="maxThreads">150</attribute>
>         <attribute name="minThreads">25</attribute>
>         <reference name="JettyContainer">
>             <name>JettyWebContainer</name>
>         </reference>
>         <reference name="KeystoreManager">
>             <name>KeystoreManager</name>
>         </reference>
>     </gbean>
>
> In this case, the keyStore, keyAlias, trustStore, algorithm,
> secureProtocol, and KeystoreManager values are all needed to create the
> SSLServerSocketFactory instance that will be used to create the SSL
> connection.
>
> Now, to enable this support for CORBA, the two beans that create the ORB
> instances (CORBABean and CSSBean) will need the same set of attributes
> (and those attributes will need to be propagated to a couple of other
> objects, which would start to get pretty messy).  Alternatively, it
> might make sense to have an SSLFactoryGBean, which is configured with
> all of the attributes above, and which has methods for creating an
> SSLSocket and a SSLServerSocket, and/or retrieving an appropriately
> configured socket factory.  This seems to me like a simpler
> implementation, allowing the two CORBA beans to just be initialized with
> the SSLFactoryGBean instance.  It might make sense to rework the
> HTTPSConnector too to use the same pattern.
>
> So, which model should be used here:
>
> 1)  Current model employed with HTTPSConnector where all KeystoreManager
> users expose/manage all of the attributes necessary to create SSL
> connections using the KeystoreManager, or
>
> 2)  Have an SSLFactory GBean where the SSL characteristics are
> configured separately from the SSL consumer?
>
> Rick
>
>

Mime
View raw message