WildFly Security Concepts

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

External

• Red Hat JBoss Enterprise Application Platform 6.4 Security Architecture https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-6.4/red-hat-jboss-enterprise-application-platform-64-security-architecture

Internal

• WildFly Security

Relevance

• EAP 6.4 August 2015

Overview

WildFly security model is based on two concepts: core management authentication and the security subsystem. The implementation includes security realms and security domains. The article uses concepts described in Security Concepts.

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 Domains

A security domain is a JBoss concept that predates the security realm, which was introduced in JBoss 7 and then WildFly. From a conceptual perspective, 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. Security domains are declared as part of the security subsystem. More details available here:

Security Domains

Relationship between a Security Realm and a Security Domain

https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/6.4/html/security_architecture/how_red_hat_jboss_enterprise_application_platform_6_handles_security_out_of_the_box#using_security_realms_and_security_domains

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

Other Subjects

• WildFly Password Vault