WildFly Security Concepts
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
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 Domain
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|JBoss7SecurityConcepts#TheSecuritySubsystem]. More details available here:
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
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:
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.