Management API Security Possible Configuration Sample

For domain management security we are looking to achieve the following: -

• Simplified configuration without need to understand inner workings of JAAS
• Configuration and implementation compatible with both SASL negotiated connections and the simpler single challenge / response we are used to.
• Option to still make use of JAAS if desired.

Sample Configuration

The following sample configuration shows the extent of the configuration to be made possible in the context of the standalone.xml descriptor.

<server xmlns="urn:jboss:domain:1.0"
...
    <management>

       <security-realms>
          <security-realm name="Management Realm">

             <server-identities>
                <certificate></certificate>
                <kerberos></kerberos>
             </server-identities>

              <authentication useDomainController="true|false">
                 <user-properties location="" />

                 <user-database connection="UsersDatabase" query="select password from Users where username=%1" />

                 <user-ldap connection="UsersDirectory">
                    <simple userDNPrefix="..." userDNSuffix="... />
                    <advanced userSearch="..." />                    
                 </user-ldap>

                 <jaas>
                    <login-module ></login-module>
                 </jaas
              </authentication>

              <authorization useDomainController="true|false">
                 <role-properties location="" />

                 <role-database connection="UsersDatabase" query="select RoleName from Rolers where User=%1" />

                 <role-ldap connection="UsersDirectory">
                    <simple userDNPrefix="..." userDNSuffix="... />
                    <advanced userSearch="..." />                    
                 </role-ldap>

                 <jaas>
                    <login-module ></login-module>
                 </jaas
              </authorization>

          </security-realm>
       </security-realms>

        <connections>
           <database name="UsersDatabase"><connection-properties/></database>
           <ldap name="UsersDirectory"><connection-properties/></ldap>
        </connections>
       <authorization-control></authorization-control>
    </management>

    <management-apis>
        <native-api interface="public" port="9991" realm="Management Realm"/>
        <http-api interface="public" port="9992" realm="Management Realm" />
    </management-apis> 
...
</server>

Description

If security is enabled the management element will hold one or more security realms, the security realm will contain 3 sub sections: -

server-identities

There are a couple of places where a server requires an identity of it's own a couple of examples are the server certificate used for SSL or a Kerberos identity when used with GSSAPI.

The identities will not be named as they are nested in the security realm, instead there will be some form of ServerIdentityManager with methods such as getX509Idenity or getKerberosIdentity.

authentication

The SASL mechanisms being used require a number of callbacks to be made available whilst the connection is negotiated, for consistency the HTTP API will follow the same approach although SASL will not be directly used.

The authentication element will list one or more 'components' for accessing user stores.  These components will advertise their capabilities so that their suitability with the currently selected SASL / HPP authentication mechanism can be verified.

  e.g. The User-Database component is expected to be able to return a password so it can be used with both Plan and Digest_MD5, the User-LDAP component will only be able to verify a password it is provided so will only work with Plain.

To allow for legacy modules a JAAS component will also be provided, this allow a list of login modules to be specified and is intended for Plain or External for the scenarios previously covered up to AS6. 

It is not intended for new modules to be supported for other negotiated mechanisms.

In the future if we choose to publish an SPI for these components we may allow for custom components to be defined.

The useDomainController attribute is to specify if the requests should be delegated to the domain controller.

authorization

The purpose of this element is to define how additional information relating to the customers identity will be loaded so that it can be used later for authorization checks - generally this would be a list of roles but other information could be added.

As for authentication this will define a number of components to access user repositories, these will be queried to load the identity information.

A JAAS option will also be available to use existing login modules for role queries.  (We will ensure these login modules are only loading the roles and not attempting authentication.)

The useDomainController attribute is to specify if the requests should be delegated to the domain controller.

connections

At a higher level a connections element will be defined, this will be used to configure all connections to external systems during the security processing - as authentication and authorization has been split this will allow for connection information to be shared with both parts.

management-apis

Within the management APIs itwill be possible to specify the security-realm that should be used for that connection.

It will be possible once the security-realm has been identified to query the server-identities and the authentication components to identify what capabilities we have.  We could decide to support the list of available mechanisms or define additional configuration on the API definition to specify the supported mechanisms.

authorization-control

This is not being defined at this stage but this is where the authorization requirements will be defined.

Domain Management

For managing a domain it will be expected that the <management> element will be defined within the domain.xml and the <management-apis> element will be defined in the host.xml.

It will also be possible to add a <management> element within the host.xml - this will allow any parts of the <management> element from the master domain controller to be overriden, possible needs for this are: -

• Host specific server identities.
• Host specific connection definitions e.g. Using a different database or different connection to same database.
• Different authentication requirements for host direct connections.