About jboss-domain-web.xml

[jfclere]

There are several weird stuff in jboss-domain-web.xml

<xs:attribute name="blocking-enabled" default="false" type="dc:boolean"/>

That is something like the Connector we are using (APR, JIO ay be NIO or other in future).

The <xs:attributeGroup name="ssl-attlist">

Can't map to the SSL attributes we need (see http://docs.jboss.org/jbossweb/en/html/docs/config/http.html).

In virtual-server-attlist the <xs:attribute name="docroot"/> doesn't look a good idea (something like serving exploded wars?).

The <xs:complexType name="http-access-logType">

Would be something corresponding to a Valve, no? Defined in the VirtualHost.

How do we define other valves? Specially the rewritevalve?

Additionally how do we define mapping? Only in the war?

[rmaucher]

Rewrite features should probably be usable from domain.xml, so that means new elements. Mapping is defined from the defaults, or explicit mappings in the deployment, I don't think we need to change that. I don't see many other valves which would need much explicit configuration. The AS specific valves that deal with the "enterprise" stuff could be grouped in a "standalone" flag, or something like it.

I may propose changing the virtual-server element (I think a virtual host should be a main name, with aliases; although the first name in the hosts list could be considered that way automagically). Not sure about the default-web-module attribute either. Is it a deployment name (like ROOT.war right now) ?

[dmlloyd]

I'd consider this to be a mockup - I think if you guys have a better vision as to what this would look like, feel free to paste in either an example schema or even some example XML (use the little ">>" button and choose "Syntax Highlighting > XML" for best results).

[rmaucher]

Here's my initial list of comments/updates:

- realm and security config becomes automatic (uses JAAS, etc)
- session manager configuration always uses the JBoss session manager
- APR connector configuration rolled in http-connector
- standalone boolean flag on web-container (optimized config without EE features)
- rewrite element on web-container
- mod_cluster configuration needs ?
- SSL attributes need to correspond between java.io and APR
- Shared JARs (for Servlet's SCI and TLD; maybe it could simply be a special, set folder), and shared web.xml config (could be placed in the sar, in a fixed location as configuration has little value)
- classloader config for WARs (package filtering, delegation, etc)

  <xs:attributeGroup name="http-connector-attlist">
    <xs:attribute name="id" use="required"/>
    <xs:attribute name="address" use="required"/>
    <xs:attribute name="port" use="required"/>
    <xs:attribute name="native" default="true" type="dc:boolean"/>
    <xs:attribute name="protocol"/>
    <xs:attribute name="scheme"/>
    <xs:attribute name="redirect-port"/>
    <xs:attribute name="secure" default="false" type="dc:boolean"/>
    <xs:attribute name="default-virtual-server"/>
    <xs:attribute name="xpowered-by"/>
    <xs:attribute name="enabled" default="true" type="dc:boolean"/>
    <xs:attribute name="executor" type="xs:IDREF" />     
  </xs:attributeGroup>

  <xs:element name="virtual-server">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="access-log" minOccurs="0" type="http-access-logType"/>
        <xs:element name="rewrite" minOccurs="0" type="http-rewriteType"/>
        <xs:element name="properties" type="dc:propertiesType" />
      </xs:sequence>
      <xs:attributeGroup ref="virtual-server-attlist"/>
    </xs:complexType>
  </xs:element>
  <xs:attributeGroup name="virtual-server-attlist">
    <xs:attribute name="id" use="required"/> -> vhost name
    <xs:attribute name="http-connectors"/>
    <xs:attribute name="default-web-module"/>
    <xs:attribute name="hosts" use="required"/> -> vhost aliases
  </xs:attributeGroup>

  <rewrite pattern="foo" substitution="bar" flags="">
     <condition test="foo" pattern="bar" flags="" />
  </rewrite>

[jfclere]

The SSL part for the connector should be something like:

  <xs:attributeGroup name="ssl-attlist">
    <xs:attribute name="keyAlias" default="jbossweb"/>
    <xs:attribute name="Password"/>
    <xs:attribute name="CertificateKeyFile" default="$user.home/.keystore"/>
    <xs:attribute name="CipherSuite" default="ALL"/>
    <xs:attribute name="Protocol" default="ALL" type="SSlProtocolType"/>
    <xs:attribute name="VerifyClient" default="none"/>
    <xs:attribute name="VerifyDepth" default="10"/>
    <xs:attribute name="CertificateFile"/>
    <xs:attribute name="CACertificateFile"/>
    <xs:attribute name="CARevocationUrl"/>
    <xs:attribute name="sessionCacheSize" default="0"/>
    <xs:attribute name="sessionTimeout" default="86400"/>
  </xs:attributeGroup>
  <xs:simpleType name="SSlProtocolType">
       <xs:restriction base="xs:token">
         <xs:enumeration value="SSLv2"/>
         <xs:enumeration value="SSLv3"/>
         <xs:enumeration value="TLSv1"/>
         <xs:enumeration value="SSLv2+SSLv3"/>
    </xs:restriction>
  </xs:simpleType>

What may need little more is:
<xs:attribute name="Password"/>
As I don't think we want to store passwords in domain.xml do we?

[rmaucher]

Good generic question indeed: how are passwords supposed to be handled by the domain model ?

[anil.saldhana]

In my view, we need to centralize the passwords such that we can either do masking or encryption as needed. The attributes that refer to the passwords in the domain model should be references to this central password structure.

[dmlloyd]

ANIL SALDHANA wrote:

In my view, we need to centralize the passwords such that we can either do masking or encryption as needed. The attributes that refer to the passwords in the domain model should be references to this central password structure.

Definitely.  Here's a few ideas:

1. Simple obfuscation.  This amounts to a simple xor-mask of the characters in the password or something like that.  Not a security measure by any stretch of the imagination; it's just to prevent passwords from getting accidentally printed out and posted around the office.
2. Use a keystore.  A password is basically a SecretKey which is composed of characters rather than bytes; putting it in the keystore amounts to mapping it to UTF-8.  So we could either list the password name in the XML or better yet just have it automatically search the keystore at a name that is derived from the domain element's identity i.e. "password.datasource.myDS" or something.  We need support for keystores anyway, at a management & tooling level.  (I believe we talked about securing the keystore password many times already: put it in a separate FS file and use FS permissions, or maybe provide a plugin point so that users can enter it in other ways e.g. via a hardware solution).
3. Use an alternative passwords file which is protected with FS permissions, but otherwise works similarly to the keystore solution up above.  Of course this is just making a keystore and calling it by a different name.

[anil.saldhana]

DML, most of your ideas are present in the Password Mask Management feature in AS5.1+

We do use keystores.  My thoughts have been toward beefing that feature (centralized password management) in association with the domain model.

I also need to get a replacement for the AOP annotation I use.

[jason.greene]

ANIL SALDHANA wrote:

DML, most of your ideas are present in the Password Mask Management feature in AS5.1+

We do use keystores.  My thoughts have been toward beefing that feature (centralized password management) in association with the domain model.

I also need to get a replacement for the AOP annotation I use.

The annotation should no longer be needed since the domain would have first class support for it. If something outside of domain.xml (som arbitrary dynamic code) needs a password, it could use a Java API. That API though could be some kind of PasswordManager thing, which is a service...

[brian.stansberry]

Emanuel pulled your input into his git repo and I massaged it a bit more; result is at http://github.com/bstansberry/jboss-as/blob/master/domain/src/main/resources/schema/jboss-domain-web.xsd

The "rewrite" element you describe was an example rather than xsd, so I roughed it out as xsd. But really don't know what attributes are required or what they mean, so feedback is appreciated.

<xs:complexType name="http-rewriteType">
        <xs:sequence>
            <xs:element name="condition" type="rewrite-conditionType" />
        </xs:sequence>
        
        <xs:attribute name="pattern" use="required">
            <xs:annotation>
                <xs:documentation>FIXME: document this attribute</xs:documentation>
            </xs:annotation>
        </xs:attribute>
        <xs:attribute name="substitution" use="required">
            <xs:annotation>
                <xs:documentation>FIXME: document this attribute</xs:documentation>
            </xs:annotation>
        </xs:attribute>
        <xs:attribute name="flags" use="required">
            <xs:annotation>
                <xs:documentation>FIXME: document this attribute</xs:documentation>
            </xs:annotation>
        </xs:attribute>
    </xs:complexType>

    <xs:complexType name="rewrite-conditionType">        
        <xs:attribute name="test" use="required">
            <xs:annotation>
                <xs:documentation>FIXME: document this attribute</xs:documentation>
            </xs:annotation>
        </xs:attribute>
        <xs:attribute name="pattern" use="required">
            <xs:annotation>
                <xs:documentation>FIXME: document this attribute</xs:documentation>
            </xs:annotation>
        </xs:attribute>
        <xs:attribute name="flags" use="required">
            <xs:annotation>
                <xs:documentation>FIXME: document this attribute</xs:documentation>
            </xs:annotation>
        </xs:attribute>
    </xs:complexType>

[brian.stansberry]

A note on style. Elsewhere in the schema we seem to have settled on lower case with "-" to separate words in our element and attribute names. So, we should be consistent:

<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>

Also, should "ALL" be in the SSLProtocolType enumeration? Or do we change the default value for the protocol attribute?

[jfclere]

ALL is missing in the SSLProtocolType enumeration.

[rmaucher]

The "rewrite" element you describe was an example rather than xsd, so I  roughed it out as xsd. But really don't know what attributes are  required or what they mean, so feedback is appreciated.

Yes, I'll write the schema if I still like these elements next week

One problem of git that is obvious to me however is that people start having their own version of things For example, I forked Emanuel's repo, and I don't even know how to apply his changes to my repo using github.

[aloubyansky]

I've fixed a couple of XSD validation issues:

- added ALL;

- changed domain's content from 'all' to unbounded 'choice' because maxOccurs in 'all' can only be 0 or 1 (in the current xsd version)

I've also added a simple XSD validation testcase based on javax.xml.validation.SchemaFactory. If anybody makes changes in XSDs I ecourage you to run the test to make sure it's all good.