WildFly Security Concepts: Difference between revisions
| Line 25: | Line 25: | ||
=Security Domain= | =Security Domain= | ||
A ''security domain'' is a JBoss concept that predates the [[#Security_Realms|security realm]]. | A ''security domain'' is a JBoss concept that predates the [[#Security_Realms|security realm]], which was introduced in JBoss 7 and then WildFly. | ||
=Relationship between a Security Realm and a Security Domain= | =Relationship between a Security Realm and a Security Domain= | ||
Revision as of 20:21, 6 March 2017
Internal
Relevance
- EAP 6.4 August 2015
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. 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.
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.