SSL definition

[jfclere]

There are already at least 2 places where we need an SSL definition: jboss-domain-mod_cluster.xsd and jboss-domain-web.xsd.

The domain-web covers JSSE and OpenSSL (read APR).

<xs:attributeGroup name="ssl-attlist">
    <xs:attribute name="key-alias" default="jbossweb"/>
    <xs:attribute name="password"/>
    <xs:attribute name="certificate-key-file" default="${user.home}/.keystore"/>
    <xs:attribute name="cipher-suite" default="ALL"/>
    <xs:attribute name="protocol" default="ALL" type="SSlProtocolType"/>
    <xs:attribute name="verify-client" default="none"/>
    <xs:attribute name="verify-depth" default="10"/>
    <xs:attribute name="certificate-file"/>
    <xs:attribute name="ca-certificate-file"/>
    <xs:attribute name="ca-revocation-url"/>
    <xs:attribute name="session-cache-size" default="0"/>
    <xs:attribute name="session-timeout" default="86400"/>
  </xs:attributeGroup>

Should that be moved in jboss-domain-common.xsd?

[aloubyansky]

What is in and how/where is jboss-domain-mod_cluster.xsd used? Is it imported by some other schema? Which one? I don't see it yet in the schema dir.

[jfclere]

jboss-domain-mod_cluster.xsd will be included in jboss-domain.xsd

[dmlloyd]

Jean-Frederic Clere wrote:

There are already at least 2 places where we need an SSL definition: jboss-domain-mod_cluster.xsd and jboss-domain-web.xsd.

The domain-web covers JSSE and OpenSSL (read APR).

<xs:attributeGroup name="ssl-attlist">
    <xs:attribute name="key-alias" default="jbossweb"/>
    <xs:attribute name="password"/>
    <xs:attribute name="certificate-key-file" default="${user.home}/.keystore"/>
    <xs:attribute name="cipher-suite" default="ALL"/>
    <xs:attribute name="protocol" default="ALL" type="SSlProtocolType"/>
    <xs:attribute name="verify-client" default="none"/>
    <xs:attribute name="verify-depth" default="10"/>
    <xs:attribute name="certificate-file"/>
    <xs:attribute name="ca-certificate-file"/>
    <xs:attribute name="ca-revocation-url"/>
    <xs:attribute name="session-cache-size" default="0"/>
    <xs:attribute name="session-timeout" default="86400"/>
  </xs:attributeGroup>

Should that be moved in jboss-domain-common.xsd?

I'm inclined to make a jboss-domain-ssl.xsd or jboss-domain-security.xsd.

Some questions though.  Why is the key in a file rather than a keystore?  Also, again I really think "protocol" should be a string to allow users to install other providers.

I think we probably need some kind of keystore element:

  <sec:keystore name="MyKeyStore" path="/path/to/blah" provider="optionalProvider" type="jceks" passwordFile="/path/to/file/with/password"/>

Also rather than just making SSL be an attribute group, what if it were an element with a cleaner structure:

  <sec:ssl-context protocol="protocolName" provider="optionalProvider" mode="client"> <!-- mode can be server -->
       <sec:cipher-suites value="blah blah2 blah3"/> <!-- JSSE allows multiple cipher suites to be enabled -->
       <sec:protocols value="blah blah2"/> <!-- JSSE allows multiple protocols to be listed -->
       <sec:require-client-auth/> <!-- optional -->
       <!-- maybe more stuff for more detailed trust/key manager config? -->
  </sec:ssl-context>

[aloubyansky]

The thing is you can't include the same schema more than once in a hierarchy of schemas. I.e.

jboss-domain.xsd includes jboss-domain-web.xsd

jboss-domain-web.xsd includes jboss-domain-common.xsd

Now, jboss-domain.xsd can't include any other schema that includes jboss-domain-common.xsd, otherwise it'll be included twice, global type and elements will be duplicated and there will be schema validation errors.

[jfclere]

Some questions though.  Why is the key in a file rather than a keystore?

Because when using APR (OpenSSL) we need files. Convertions are tricky there.

Also, again I really think "protocol" should be a string to allow users  to install other providers.

Well the problem will be how to configure those.

[jfclere]

hm we are going to have 1 schema at the end... For the moment jboss-domain-web.xsd includes jboss-domain-common.xsd so that we are able to validate it, no?

[jfclere]

BTW: I have push in my improved version of the stuff with a description of the attributes.

[brian.stansberry]

Things have moved back to separate namespaces for different subsystems. I'd request that jboss-domain-web.xsd and your mod_cluster xsd use their own namespace, but the implications of separate namespaces are still being worked through, so I don't mind keeping things as they are for a couple days.

If we have separate namespaces, then the security configuration stuff would come from a security-specific namespace, a la David's example above.

The implication of that is elements from the security namespace would be declared outside of the mod_cluster elements (in a security-related area), and the mod_cluster elements would reference the SSL configuration by name. Similar to the socket-binding thing I pointed out.[1] It then becomes the responsibility of the domain model's validation logic to ensure that whatever SSL configuration mod_cluster names actually exists.

At this point we have 3 types of things where we're talking about using this kind of approach:

1) Socket binding definitions [1]

2) Thread pool definitions

3) SSL

Probably other security stuff too.

[1] http://community.jboss.org/thread/153975?tstart=0

[aloubyansky]

Jean-Frederic Clere wrote:

hm we are going to have 1 schema at the end... For the moment jboss-domain-web.xsd includes jboss-domain-common.xsd so that we are able to validate it, no?

I'd say including it the web schema becomes a standalone self-sufficient/complete schema. Without it it's just a piece of XSD which can't be used anywhere and must be included with the requirement that the including XSD must also include the common schema.

[dmlloyd]

Jean-Frederic Clere wrote:

Some questions though.  Why is the key in a file rather than a keystore?

Because when using APR (OpenSSL) we need files. Convertions are tricky there.

Interesting, you can't even pass in e.g. a byte array or character stream?

In any case, OpenSSL configuration seems pretty different from JSSE.  It might make sense to have separate element types.  For example Remoting doesn't support OpenSSL (yet), so it would only take a JSSE configuration.

Thoughts on that?

Jean-Frederic Clere wrote:

Also, again I really think "protocol" should be a string to allow users  to install other providers.

Well the problem will be how to configure those.

What is to configure?  Either a protocol is installed, or it isn't.  Part of the security subsystem should be the ability to register new providers:

    <subsystem name="security">
        <sec:provider module="org.foo:my-provider-module"/>
    </subsystem>

...which loads the security provider via:

    ...
    for (Provider p : module.loadService(Provider.class)) {
        Security.addProvider(p);
    }
    ...

which uses the JDK ServiceLoader mechanism.

[dmlloyd]

Alexey Loubyansky wrote:

Jean-Frederic Clere wrote:

hm we are going to have 1 schema at the end... For the moment jboss-domain-web.xsd includes jboss-domain-common.xsd so that we are able to validate it, no?

I'd say including it the web schema becomes a standalone self-sufficient/complete schema. Without it it's just a piece of XSD which can't be used anywhere and must be included with the requirement that the including XSD must also include the common schema.

Yeah I agree, and I would take it farther: I think that one namespace, one schema file is best overall.  Hopefully with splitting namespaces by subsystem we'll be able to achieve that since the domain schema file will be moderately sized.  The subsystem schema files would possibly import the domain namespace, but the domain schema should be able to stand on its own.

[jfclere]

Some questions though.  Why is the key in a file rather than a  keystore?  Also, again I really think "protocol" should be a string to  allow users to install other providers.

Well OpenSSL is a toobox the default is to use (a lot of) files but it would be possible to read the keystore and convert it into a openSSL X509 storage via X509_STORE_add_cert() and other or to write our own X509_LOOKUP_METHOD to read/write the stuff we need from/in a keystore. For that we need to extent JBossNative.

[jfclere]

Ok in fact we just need something like test-jboss-domain-mod_cluster.xsd to test jboss-domain-mod_cluster.xsd

[jfclere]

In any case, OpenSSL configuration seems pretty different from JSSE.   It might make sense to have separate element types.  For example  Remoting doesn't support OpenSSL (yet), so it would only take a JSSE  configuration.

Thoughts  on that?

How does JSSE works with sslengines (boxes that do the encrypt/decrypt)?

Well we can start without OpenSSL and add it later.