WildFly Security Concepts

in process of being migrated from https://home.feodorov.com:9443/wiki/Wiki.jsp?page=JBoss7SecurityConcepts

Internal

• WildFly Security

Relevance

• EAP 6.4 August 2015

Diagram

Security Realms

A security realm is a WildFly-specific identity store of usernames, passwords and group membership information that can be used to authenticate users of the management interfaces, web applications and EJBs. The default configuration includes a Management Realm and an Application Realm. For more details, see

Security Realms

Security Domain

A security domain is a JBoss concept that predates the security realm, which was introduced in JBoss 7 and then WildFly.

Relationship between a Security Realm and a Security Domain

Web and EJB applications can only use security domains directly. The security domain perform the actual authentication and authorization by delegating to login modules.

The identity information managed by a security realm can be used by a security domain: for example, the "other" security domain uses the authentication information contained by the Application Realm and exposes it for use by applications. Web applications and EJB deployments cannot be configured to directly use Security Realms for authentication. Only the core management and EJB remoting end points can use Security Realms directly.

An example of delegating to a security realm (to verify that it actually works and it is the most up to date configuration.):

<subsystem xmlns="urn:jboss:domain:security:1.1">
   <security-domains>
      <security-domain name="other" cache-type="default">
         <authentication>
             <login-module code="RealmUsersRoles" flag="required">
                <module-option name="usersProperties" value="${jboss.server.config.dir}/application-users.properties"/>
                <module-option name="rolesProperties" value="${jboss.server.config.dir}/application-roles.properties"/>
                <module-option name="realm" value="ApplicationRealm"/>
                <module-option name="password-stacking" value="useFirstPass"/>
             </login-module>
         </authentication>
      </security-domain>
     ...
   </security domains>
</subsystem>

The Security Subsystem

Security Subsystem Concepts

Subordinated Host Controller Identity

Subordinated host controllers must authenticate against the domain controller's Management Realm in order to be able to interact with it. The host controller identity is associated to a domain controller's Management Realm user whose name is identical with the host controller's host name (the <host name="..."> element in the host controller's host.xml.

From the domain controller's perspective, the host controller identity is established by adding a regular Management Realm user. This is done with the add-user.sh utility, as described here:

Adding a User to the Management Realm

Server Identity Secret

A Management Realm user authenticates with a regular password, so the host controllers will also have to use the same mechanism - password - to authenticate. The password is is known as server identity secret on the host controller, and it is specified in its host.xml:

<host name="..." ...>
  <management>
    <security-realms>
      <security-realm name="ManagementRealm">
        ...
        <server-identities>
          <secret value="bjFfMTIz"/>
        </server-identities>
      </security-realm>
    ...
</host>

The secret maintained in the <server-identities> section of host.xml is the hashed value of the domain controller Management Realm user's password. Given the password value, the secret value can be calculated as follows:

echo -n "myPassword" | openssl enc -base64

Otherwise, the secret's value is displayed during the process of adding the user to the Management Realm on the domain controller. The value displayed by add-user.sh is identical with the one calculated with openssl. They can be used interchangeably.

Subordinated Host Controller Identity Configuration

Subordinated Host Controller Identity Configuration