WildFly Security Domains

Internal

• WildFly Security Concepts

Overview

A security domain is a set of Java Authentication and Authorization Service (JAAS) declarative security configurations used by one or more applications to control authentication, authorization and security auditing. An application specifies a security domain to manage its security information. Security domains are declared as part of the security subsystem. A security domain is a JBoss concept that predates the security realm, which was introduced in JBoss 7 and then WildFly.

Security domains are declared in the JBoss configuration files (domain.xml or standalone.xml) as part of the security subsystem. Since the security domains are part of the security subsystem, they are loaded after core services.

Users can create custom security domains, as shown here Adding a New Security Domain

Default Security Domains

An application server instance comes with three security domains pre-configured: "other", "jboss-ejb-policy" and "jboss-web-policy". "jboss-ejb-policy" and "jboss-web-policy" are the default authorization mechanisms that are used if the application's configured security domain has none. These security domains, along with "other" are also used internally by JBoss and therefore are required for correct operation.

Relationship between a Security Realm and a Security Domain

Relationship between a Security Realm and a Security Domain

Security Domain Caching

The authentication information caching is done by org.jboss.security.authentication.JBossCachedAuthenticationManager.

Security Domain Caching Configuration

The caching is turned on by using the "cache-type" attribute in the security-domain element. If no attribute is found, the caching is disabled. Valid values: "default" or "infinispan"

<subsystem xmlns="urn:jboss:domain:security:1.2">
    <security-domain name="other" cache-type="default">
    ...
    </security-domain>
</subsystem>

The "default" cache is a simple ConcurrentMap<Principal, DomainInfo> which does not seem to have any configurable expiration mechanism. Once a principal is placed into the cache, it does not seem to be able to expire by itself, unless flushCache(Principal) is explicitly called. In order to get the entires to expire in a configurable manner, "infinispan" should be used, as shown below:

<subsystem xmlns="urn:jboss:domain:security:1.2">
    <security-domain name="other" cache-type="infinispan">
    ...
    </security-domain>
</subsystem>

...

<subsystem xmlns="urn:jboss:domain:infinispan:1.5">
    <cache-container name="security" default-cache="auth-cache">
        <local-cache name="auth-cache" batching="true">
            <expiration lifespan="10000"/>
        </local-cache>
   </cache-container>
   ...
</subsystem>

For more details on Infinispan expiration configuration see:

Infinispan Expiration

Security Auditing

Security auditing refers to triggering events such as writing a log, in response to an event that happens within the security subsystem. Auditing mechanisms are configured as part of a security domain. Auditing uses provider modules to control the way the security events are reported. The core management also has its own security auditing and logging functionality that is configured separately and it is not part of the security subsystem.