WildFly Security Domains: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
 
(5 intermediate revisions by the same user not shown)
Line 18: Line 18:


{{Internal|WildFly_Security_Concepts#Relationship_between_a_Security_Realm_and_a_Security_Domain|Relationship between a Security Realm and a Security Domain}}
{{Internal|WildFly_Security_Concepts#Relationship_between_a_Security_Realm_and_a_Security_Domain|Relationship between a Security Realm and a Security Domain}}
=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.


=Security Domain Caching=
=Security Domain Caching=
Line 39: Line 35:
</pre>
</pre>


The "default" cache is a simple <tt>ConcurrentMap<Principal, DomainInfo></tt> which does not seem to have any configurable expiration mechanism. The cache can be flushed explicitly for a principal, but there is no functionality that would expire an entry. In order to get the entires to expire, "infinispan" should be used, as shown below:
The "default" cache is a simple <tt>ConcurrentMap<Principal, DomainInfo></tt> 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 <tt>flushCache(Principal)</tt> is explicitly called. In order to get the entires to expire in a configurable manner, "infinispan" should be used, as shown below:


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


<subsystem xmlns="urn:jboss:domain:infinispan:1.5">
<subsystem xmlns="urn:jboss:domain:infinispan:1.5">
Line 53: Line 51:
             <expiration lifespan="10000"/>
             <expiration lifespan="10000"/>
         </local-cache>
         </local-cache>
    </cache-container>
  </cache-container>
  ...
</subsystem>
</pre>
</pre>
For more details on Infinispan expiration configuration see:
{{Internal|Infinispan_Expiration|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.

Latest revision as of 22:37, 6 March 2017

Internal

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.