Chapter 5. Securing the Management Interfaces with LDAP The management interfaces can authenticate against an LDAP server (including Microsoft Active Directory). This is accomplished by using an LDAP authenticator. An LDAP authenticator operates by first establishing a connection (using an outbound LDAP connection) to the remote directory server. It then performs a search using the username which the user passed to the authentication system, to find the fully-qualified distinguished name (DN) of the LDAP record. If successful, a new connection is established, using the DN of the user as the credential, and password supplied by the user. If this second connection and authentication to the LDAP server is successful, the DN is verified to be valid and authentication has succeeded. Note Securing the management interfaces with LDAP changes the authentication from digest to BASIC/Plain, which by default, will cause usernames and passwords to be sent unencrypted over the network. SSL/TLS can be enabled on the outbound connection to encrypt this traffic and avoid sending this information in the clear. Important In cases where a legacy security realm uses an LDAP server to perform authentication, such as securing the management interfaces using LDAP, JBoss EAP will return a 500 , or internal server error, error code if that LDAP server is unreachable. This behavior differs from versions of JBoss EAP which returned a 401 , or unauthorized, error code under the same conditions. 5.1. Using Elytron You can secure the management interfaces using LDAP with the elytron subsystem in the same way as using any identity store. Information on using identity stores for security with the elytron subsystem can be found in the Secure the Management Interfaces with a New Identity Store section of How to Configure Server Security . For example, to secure the management console with LDAP: Note If the JBoss EAP server does not have permissions to read the password, such as when an Active Directory LDAP server is used, it is necessary to set direct-verification to true on the defined LDAP realm. This attribute allows verification to be directly performed on the LDAP server instead of the JBoss EAP server. Example LDAP Identity Store 5.1.1. Using Elytron for Two-way SSL/TLS for the Outbound LDAP Connection When using LDAP to secure the management interfaces, you can configure the outbound LDAP connection to use two-way SSL/TLS. To do this, create an ssl-context and add it to the dir-context used by your ldap-realm . Creating a two-way SSL/TLS ssl-context is covered in the Enable Two-way SSL/TLS for Applications using the Elytron Subsystem section of How to Configure Server Security . Warning Red Hat recommends that SSLv2, SSLv3, and TLSv1.0 be explicitly disabled in favor of TLSv1.1 or TLSv1.2 in all affected packages. 5.2. Using Legacy Core Management Authentication To use an LDAP directory server as the authentication source for the management interfaces using the legacy security subsystem, the following steps must be performed: Create an outbound connection to the LDAP server. The purpose of creating an outbound LDAP connection is to allow the security realm (and the JBoss EAP instance) to establish a connection to the LDAP server. This is similar to the case of creating a datasource for use with the Database login module in a security domain. The LDAP outbound connection allows the following attributes: Attribute Required Description url yes The URL address of the directory server. search-dn no The fully distinguished name (DN) of the user authorized to perform searches. search-credential no The password of the user authorized to perform searches. The attributes supported by this element are: store - Reference to the credential store to obtain the search credential from. alias - The alias of the credential in the referenced store. type - The fully qualified class name of the credential type to obtain from the credential store. clear-text - Instead of referencing a credential store, this attribute can be used to specify a clear text password. initial-context-factory no The initial context factory to use when establishing the connection. Defaults to com.sun.jndi.ldap.LdapCtxFactory . security-realm no The security realm to reference to obtain a configured SSLContext to use when establishing the connection. referrals no Specifies the behavior when encountering a referral when doing a search. Valid options are IGNORE , FOLLOW , and THROW . IGNORE : The default option. Ignores the referral. FOLLOW : When referrals are encountered during a search, the DirContext being used will attempt to follow that referral. This assumes the same connection settings can be used to connect to the second server and the name used in the referral is reachable. THROW : The DirContext will throw an exception, LdapReferralException , to indicate that a referral is required. The security realm will handle and attempt to identify an alternative connection to use for the referral. always-send-client-cert no By default the server's client certificate is not sent while verifying the users credential. If this is set to true it will always be sent. handles-referrals-for no Specifies the referrals a connection can handle. If specifying list of URIs, they should be separated by spaces. This enables a connection with connection properties to be defined and used when different credentials are needed to follow a referral. This is useful in situations where different credentials are needed to authenticate against the second server, or for situations where the server returns a name in the referral that is not reachable from the JBoss EAP installation and an alternative address can be substituted. Note search-dn and search-credential are different from the username and password provided by the user. The information provided here is specifically for establishing an initial connection between the JBoss EAP instance and the LDAP server. This connection allows JBoss EAP to perform a subsequent search for the DN of the user trying to authenticate. The DN of the user, which is a result of the search, that is trying to authenticate and the password they provided are used to establish a separate second connection for completing the authentication process. Given the following example LDAP server, below are the management CLI commands for configuring an outbound LDAP connection: Table 5.1. Example LDAP Server Attribute Value url 127.0.0.1:389 search-credential myPass search-dn cn=search,dc=acme,dc=com CLI for Adding the Outbound Connection Note This creates an unencrypted connection between the JBoss EAP instance and the LDAP server. For more details on setting up an encrypted connection using SSL/TLS, see Using SSL/TLS for the Outbound LDAP Connection . Create a new LDAP-enabled security realm. Once the outbound LDAP connection has been created, a new LDAP-enabled security realm must be created to use it. The LDAP security realm has the following configuration attributes: Attribute Description connection The name of the connection defined in outbound-connections to use to connect to the LDAP directory. base-dn The DN of the context to begin searching for the user. recursive Whether the search should be recursive throughout the LDAP directory tree, or only search the specified context. Defaults to false . user-dn The attribute of the user that holds the DN. This is subsequently used to test authentication as the user can complete. Defaults to dn . allow-empty-passwords This attribute determines whether an empty password is accepted. The default value is false . username-attribute The name of the attribute to search for the user. This filter performs a simple search where the user name entered by the user matches the specified attribute. advanced-filter The fully defined filter used to search for a user based on the supplied user ID. This attribute contains a filter query in standard LDAP syntax. The filter must contain a variable in the following format: {0} . This is later replaced with the user name supplied by the user. More details and advanced-filter examples can be found in the Combining LDAP and RBAC for Authorization section . Warning It is important to ensure that empty LDAP passwords are not allowed since it is a serious security concern. Unless this behavior is specifically desired in the environment, ensure empty passwords are not allowed and allow-empty-passwords remains false. Below are the management CLI commands for configuring an LDAP-enabled security realm using the ldap-connection outbound LDAP connection. /core-service=management/security-realm=ldap-security-realm:add /core-service=management/security-realm=ldap-security-realm/authentication=ldap:add(connection="ldap-connection", base-dn="cn=users,dc=acme,dc=com",username-attribute="sambaAccountName") reload Reference the new security realm in the management interface. Once a security realm has been created and is using the outbound LDAP connection, that new security realm must be referenced by the management interfaces. /core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value="ldap-security-realm") Note The management CLI commands shown assume that you are running a JBoss EAP standalone server. For more details on using the management CLI for a JBoss EAP managed domain, see the JBoss EAP Management CLI Guide . 5.2.1. Using Two-way SSL/TLS for the Outbound LDAP Connection Follow these steps to create an outbound LDAP connection secured by SSL/TLS: Warning Red Hat recommends that SSLv2, SSLv3, and TLSv1.0 be explicitly disabled in favor of TLSv1.1 or TLSv1.2 in all affected packages. Configure a security realm for the outbound LDAP connection to use. The security realm must contain a keystore configured with the key that the JBoss EAP server will use to decrypt/encrypt communications between itself and the LDAP server. This keystore will also allow the JBoss EAP instance to verify itself against the LDAP server. The security realm must also contain a truststore that contains the LDAP server's certificate, or the certificate of the certificate authority used to sign the LDAP server's certificate. See Setting up Two-Way SSL/TLS for the Management Interfaces in the JBoss EAP How to Configure Server Security guide for instructions on configuring keystores and truststores and creating a security realm that uses them. Create an outbound LDAP connection with the SSL/TLS URL and security realm. Similar to the process defined in Using Legacy Core Management Authentication , an outbound LDAP connection should be created, but using the SSL/TLS URL for the LDAP server and the SSL/TLS security realm. Once the outbound LDAP connection and SSL/TLS security realm for the LDAP server have been created, the outbound LDAP connection needs to be updated with that information. Example CLI for Adding the Outbound Connection with an SSL/TLS URL /core-service=management/ldap-connection=ldap-connection/:add(search-credential=myPass, url=ldaps://LDAP_HOST:LDAP_PORT, search-dn="cn=search,dc=acme,dc=com") Adding the security realm with the SSL/TLS certificates /core-service=management/ldap-connection=ldap-connection:write-attribute(name=security-realm,value="CertificateRealm") reload Create a new security realm that uses the outbound LDAP connection for use by the management interfaces. Follow the steps Create a new LDAP-Enabled Security Realm and Reference the new security realm in the Management Interface from the procedure in Using Legacy Core Management Authentication . Note The management CLI commands shown assume that you are running a JBoss EAP standalone server. For more details on using the management CLI for a JBoss EAP managed domain, see the JBoss EAP Management CLI Guide . 5.3. LDAP and RBAC RBAC (Role-Based Access Control) is a mechanism for specifying a set of permissions (roles) for management users. This allows users to be granted different management responsibilities without giving them full, unrestricted access. For more details on RBAC, see the Role-Based Access Control section of the JBoss EAP Security Architecture guide . RBAC is used only for authorization, with authentication being handled separately. Since LDAP can be used for authentication as well as authorization, JBoss EAP can be configured in the following ways: Use RBAC for authorization only, and use LDAP, or another mechanism, only for authentication. Use RBAC combined with LDAP for making authorization decisions in the management interfaces. 5.3.1. Using LDAP and RBAC Independently JBoss EAP allows for authentication and authorization to be configured independently in security realms. This enables LDAP to be configured as an authentication mechanism and RBAC to be configured as an authorization mechanism. If configured in this manner, when a user attempts to access a management interface, they will first be authenticated using the configured LDAP server. If successful, the user's role, and configured permissions of that role, will be determined using only RBAC, independently of any group information found in the LDAP server. For more details on using just RBAC as an authorization mechanism for the management interfaces, see How to Configure Server Security for JBoss EAP. For more details on configuring LDAP for authentication with the management interfaces, see the section . 5.3.2. Combining LDAP and RBAC for Authorization Users who have authenticated using an LDAP server or using a properties file can be members of user groups. A user group is simply an arbitrary label that can be assigned to one or more users. RBAC can be configured to use this group information to automatically assign a role to a user or exclude a user from a role. An LDAP directory contains entries for user accounts and groups, cross referenced by attributes. Depending on the LDAP server configuration, a user entity can map the groups the user belongs to through memberOf attributes; a group entity can map which users belong to it through uniqueMember attributes; or a combination of the two. Once a user is successfully authenticated to the LDAP server, a group search is performed to load that user's group information. Depending on the directory server in use, group searches can be performed using their SN, which is usually the username used in authentication, or by using the DN of the user's entry in the directory. Group searches ( group-search ) as well as mapping between a username and a distinguished name ( username-to-dn ) are configured when setting up LDAP as an authorization mechanism in a security realm. Once a user's group membership information is determined from the LDAP server, a mapping within the RBAC configuration is used to determine what roles a user has. This mapping is configured to explicitly include or exclude groups as well as individual users. Note The authentication step of a user connecting to the server always happens first. Once the user is successfully authenticated the server loads the user's groups. The authentication step and the authorization step each require a connection to the LDAP server. The security realm optimizes this process by reusing the authentication connection for the group loading step. 5.3.2.1. Using group-search There are two different styles that can be used when searching for group membership information: Principal to Group and Group to Principal . Principal to Group has the user's entry containing references to the groups it is a member of, using the memberOf attribute. Group to Principal has the group's entry contain the references to the users who are members of it, using the uniqueMember attribute. Note JBoss EAP supports both Principal to Group as well as Group to Principal searches, but Principal to Group is recommended over Group to Principal. If Principal to Group is used, group information can be loaded directly by reading attributes of known distinguished names without having to perform any searches. Group to Principal requires extensive searches to identify the all groups that reference a user. Both Principal to Group and Group to Principal use group-search which contains the following attributes: Attribute Description group-name This attribute is used to specify the form that should be used for the group name returned as the list of groups of which the user is a member. This can either be the simple form of the group name or the group's distinguished name. If the distinguished name is required this attribute can be set to DISTINGUISHED_NAME . Defaults to SIMPLE . iterative This attribute is used to indicate if, after identifying the groups a user is a member of, it should also iteratively search based on the groups to identify which groups the groups are a member of. If iterative searching is enabled, it keeps going until either it reaches a group that is not a member if any other groups or a cycle is detected. Defaults to false . group-dn-attribute On an entry for a group which attribute is its distinguished name. Defaults to dn . group-name-attribute On an entry for a group which attribute is its simple name. Defaults to uid . Note Cyclic group membership is not a problem. A record of each search is kept to prevent groups that have already been searched from being searched again. Important For iterative searching to work, the group entries need to look the same as user entries. The same approach used to identify the groups a user is a member of is then used to identify the groups of which the group is a member. This would not be possible if, for group to group membership, the name of the attribute used for the cross reference changes, or if the direction of the reference changes. Principal to Group (memberOf) for Group Search Consider an example where a user TestUserOne who is a member of GroupOne , and GroupOne is in turn a member of GroupFive . The group membership would be shown by the use of a memberOf attribute at the member level. This means, TestUserOne would have a memberOf attribute set to the dn of GroupOne . GroupOne in turn would have a memberOf attribute set to the dn of GroupFive . To use this type of searching, the principal-to-group element is added to the group-search element: Principal to Group, memberOf, Configuration Important The above example assumes you already have ldap-connection defined. You also need to configure the authentication mechanism which is covered earlier in this section . Notice that the group-attribute attribute is used with the group-search=principal-to-group . For reference: Table 5.2. principal-to-group Attribute Description group-attribute The name of the attribute on the user entry that matches the distinguished name of the group the user is a member of. Defaults to memberOf . prefer-original-connection This value is used to indicate which group information to prefer when following a referral. Each time a principal is loaded, attributes from each of their group memberships are subsequently loaded. Each time attributes are loaded, either the original connection or connection from the last referral can be used. Defaults to true . Group to Principal, uniqueMember, Group Search Consider the same example as Principal to Group where a user TestUserOne who is a member of GroupOne , and GroupOne is in turn a member of GroupFive . However, in this case the group membership would be shown by the use of the uniqueMember attribute set at the group level. This means that GroupFive would have a uniqueMember set to the dn of GroupOne . GroupOne in turn would have a uniqueMember set to the dn of TestUserOne . To use this type of searching, the group-to-principal element is added to the group-search element: Group to Principal, uniqueMember, Configuration Important The above example assumes you already have ldap-connection defined. You also need to configure the authentication mechanism which is covered earlier in this section . Notice that the principal-attribute attribute is used with group-search=group-to-principal . group-to-principal is used to define how searches for groups that reference the user entry will be performed, and principal-attribute is used to define the group entry that references the principal. For reference: Table 5.3. group-to-principal Attribute Description base-dn The distinguished name of the context to use to begin the search. recursive Whether sub-contexts also be searched. Defaults to false . search-by The form of the role name used in searches. Valid values are SIMPLE and DISTINGUISHED_NAME . Defaults to DISTINGUISHED_NAME . prefer-original-connection This value is used to indicate which group information to prefer when following a referral. Each time a principal is loaded, attributes from each of their group memberships are subsequently loaded. Each time attributes are loaded, either the original connection or connection from the last referral can be used. Table 5.4. membership-filter Attribute Description principal-attribute The name of the attribute on the group entry that references the user entry. Defaults to member . 5.3.2.2. Using username-to-dn It is possible to define rules within the authorization section to convert a user's simple user name to their distinguished name. The username-to-dn element specifies how to map the user name to the distinguished name of their entry in the LDAP directory. This element is optional and only required when both of the following are true: The authentication and authorization steps are against different LDAP servers. The group search uses the distinguished name. Note This could also be applicable in instances where the security realm supports both LDAP and Kerberos authentication and a conversion is needed for Kerberos, if LDAP authentication has been performed the DN discovered during authentication can be used. It contains the following attributes: Table 5.5. username-to-dn Attribute Description force The result of a user name to distinguished name mapping search during authentication is cached and reused during the authorization query when the force attribute is set to false . When force is true , the search is performed again during authorization while loading groups. This is typically done when different servers perform authentication and authorization. username-to-dn can be configured with one of the following: username-is-dn This specifies that the user name entered by the remote user is the user's distinguished name. username-is-dn Example This defines a 1:1 mapping and there is no additional configuration. username-filter A specified attribute is searched for a match against the supplied user name. username-filter Example Attribute Description base-dn The distinguished name of the context to begin the search. recursive Whether the search will extend to sub contexts. Defaults to false . attribute The attribute of the user's entry to try and match against the supplied user name. Defaults to uid . user-dn-attribute The attribute to read to obtain the user's distinguished name. Defaults to dn . advanced-filter This option uses a custom filter to locate the user's distinguished name. advanced-filter Example For the attributes that match those in the username-filter example, the meaning and default values are the same. There is one additional attribute: Attribute Description filter Custom filter used to search for a user's entry where the user name will be substituted in the {0} placeholder. Important This must remain valid after the filter is defined so if any special characters are used (such as & ) ensure the proper form is used. For example &amp; for the & character. 5.3.2.3. Mapping LDAP Group Information to RBAC Roles Once the connection to the LDAP server has been created and the group searching has been properly configured, a mapping needs to be created between the LDAP groups and RBAC roles. This mapping can be both inclusive as well as exclusive, and enables users to be automatically assigned one or more roles based on their group membership. Warning If RBAC is not already configured, pay close attention when doing so, especially if switching to a newly-created LDAP-enabled realm. Enabling RBAC without having users and roles properly configured could result in administrators being unable to login to the JBoss EAP management interfaces. Note The management CLI commands shown assume that you are running a JBoss EAP standalone server. For more details on using the management CLI for a JBoss EAP managed domain, see the JBoss EAP Management CLI Guide . Ensure RBAC is Enabled and Configured Before mappings between LDAP and RBAC Roles can be used, RBAC must enabled and initially configured. /core-service=management/access=authorization:read-attribute(name=provider) It should yield the following result: { "outcome" => "success", "result" => "rbac" } For more information on enabling and configuring RBAC, see Enabling Role-Based Access Control in How to Configure Server Security for JBoss EAP. Verify Existing List of Roles Use the read-children-names operation to get a complete list of the configured roles: /core-service=management/access=authorization:read-children-names(child-type=role-mapping) Which should yield a list of roles: { "outcome" => "success", "result" => [ "Administrator", "Deployer", "Maintainer", "Monitor", "Operator", "SuperUser" ] } In addition, all existing mappings for a role can be checked: /core-service=management/access=authorization/role-mapping=Administrator:read-resource(recursive=true) { "outcome" => "success", "result" => { "include-all" => false, "exclude" => undefined, "include" => { "user-theboss" => { "name" => "theboss", "realm" => undefined, "type" => "USER" }, "user-harold" => { "name" => "harold", "realm" => undefined, "type" => "USER" }, "group-SysOps" => { "name" => "SysOps", "realm" => undefined, "type" => "GROUP" } } } } Configure a Role-Mapping entry If a role does not already have a Role-Mapping entry, one needs to be created. For instance: /core-service=management/access=authorization/role-mapping=Auditor:read-resource() { "outcome" => "failed", "failure-description" => "WFLYCTL0216: Management resource '[ (\"core-service\" => \"management\"), (\"access\" => \"authorization\"), (\"role-mapping\" => \"Auditor\") ]' not found" } To add a role mapping: /core-service=management/access=authorization/role-mapping=Auditor:add() { "outcome" => "success" } To verify: /core-service=management/access=authorization/role-mapping=Auditor:read-resource() { "outcome" => "success", "result" => { "include-all" => false, "exclude" => undefined, "include" => undefined } } Add Groups to the Role for Inclusion and Exclusion Groups can be added for inclusion or exclusion from a role. Note The exclusion mapping takes precedence or the inclusion mapping. To add a group for inclusion: /core-service=management/access=authorization/role-mapping=Auditor/include=group-GroupToInclude:add(name=GroupToInclude, type=GROUP) To add a group for exclusion: /core-service=management/access=authorization/role-mapping=Auditor/exclude=group-GroupToExclude:add(name=GroupToExclude, type=GROUP) To check the result: /core-service=management/access=authorization/role-mapping=Auditor:read-resource(recursive=true) { "outcome" => "success", "result" => { "include-all" => false, "exclude" => { "group-GroupToExclude" => { "name" => "GroupToExclude", "realm" => undefined, "type" => "GROUP" } }, "include" => { "group-GroupToInclude" => { "name" => "GroupToInclude", "realm" => undefined, "type" => "GROUP" } } } } Removing a Group from exclusion or inclusion in an RBAC Roles Groups To remove a group from inclusion: /core-service=management/access=authorization/role-mapping=Auditor/include=group-GroupToInclude:remove To remove a group from exclusion: /core-service=management/access=authorization/role-mapping=Auditor/exclude=group-GroupToExclude:remove 5.4. Enabling Caching Security Realms also offer the ability to cache the results of LDAP queries for both authentication as well as group loading. This enables the results of different queries to be reused across multiple searches by different users in certain circumstances, for example iteratively querying the group membership information of groups. There are three different caches available, each of which are configured separately and operate independently: authentication group-to-principal username-to-dn 5.4.1. Cache Configuration Even though the caches are independent of one another, all three are configured in the same manner. Each cache offers the following configuration options: Attribute Description type This defines the eviction strategy that the cache will adhere to. Options are by-access-time and by-search-time . by-access-time evicts items from the cache after a certain period of time has elapsed since their last access. by-search-time evicts items based on how long they have been in the cache regardless of their last access. eviction-time This defines the time (in seconds) used for evictions depending on the strategy. cache-failures This is a boolean that enables/disables the caching of failed searches. This has the potential for preventing an LDAP server from being repeatedly accessed by the same failed search, but it also has the potential to fill up the cache with searches for users that do not exist. This setting is particularly important for the authentication cache. max-cache-size This defines maximum size (number of items) of the cache, which in-turn dictates when items will begin getting evicted. Old items are evicted from the cache to make room for new authentication and searches as needed, meaning max-cache-size will not prevent new authentication attempts or searches from occurring. 5.4.2. Example Note This example assumes a security realm, named LDAPRealm , has been created. It connects to an existing LDAP server and is configured for authentication and authorization. The commands to display the current configuration are detailed in Reading the Current Cache Configuration . More details on creating a security realm that uses LDAP can be found in Using Legacy Core Management Authentication . Example Base Configuration "core-service" : { "management" : { "security-realm" : { "LDAPRealm" : { "authentication" : { "ldap" : { "allow-empty-passwords" : false, "base-dn" : "...", "connection" : "MyLdapConnection", "recursive" : false, "user-dn" : "dn", "username-attribute" : "uid", "cache" : null } }, "authorization" : { "ldap" : { "connection" : "MyLdapConnection", "group-search" : { "group-to-principal" : { "base-dn" : "...", "group-dn-attribute" : "dn", "group-name" : "SIMPLE", "group-name-attribute" : "uid", "iterative" : true, "principal-attribute" : "uniqueMember", "search-by" : "DISTINGUISHED_NAME", "cache" : null } }, "username-to-dn" : { "username-filter" : { "attribute" : "uid", "base-dn" : "...", "force" : false, "recursive" : false, "user-dn-attribute" : "dn", "cache" : null } } } }, } } } } In all areas where "cache" : null appear, a cache may be configured: Authentication During authentication, the user's distinguished name is discovered using this definition and an attempt to connect to the LDAP server and verify their identity is made using these credentials. A group-search definition There is the group search definition. In this case it is an iterative search because iterative is set to true in the sample configuration above. First, a search will be performed to find all groups the user is a direct member of. After that, a search will be performed for each of those groups to identify if they have membership to other groups. This process continues until either a cyclic reference is detected or the final groups are not members of any further groups. A username-to-dn definition in group search Group searching relies on the availability of the user's distinguished name. This section is not used in all situations, but it can be used as a second attempt to discover a user's distinguished name. This can be useful, or even required, when a second form of authentication is supported, for example local authentication. 5.4.2.1. Reading the Current Cache Configuration Note The CLI commands used in this and subsequent sections use LDAPRealm for the name of the security realm. This should be substituted for the name of the actual realm being configured. CLI Command to Read the Current Cache Configuration /core-service=management/security-realm=LDAPRealm:read-resource(recursive=true) Output { "outcome" => "success", "result" => { "map-groups-to-roles" => true, "authentication" => { "ldap" => { "advanced-filter" => undefined, "allow-empty-passwords" => false, "base-dn" => "dc=example,dc=com", "connection" => "ldapConnection", "recursive" => true, "user-dn" => "dn", "username-attribute" => "uid", "cache" => undefined } }, "authorization" => { "ldap" => { "connection" => "ldapConnection", "group-search" => { "principal-to-group" => { "group-attribute" => "description", "group-dn-attribute" => "dn", "group-name" => "SIMPLE", "group-name-attribute" => "cn", "iterative" => false, "prefer-original-connection" => true, "skip-missing-groups" => false, "cache" => undefined } }, "username-to-dn" => { "username-filter" => { "attribute" => "uid", "base-dn" => "ou=Users,dc=jboss,dc=org", "force" => true, "recursive" => false, "user-dn-attribute" => "dn", "cache" => undefined } } } }, "plug-in" => undefined, "server-identity" => undefined } } 5.4.2.2. Enabling a Cache Note The management CLI commands used in this and subsequent sections configure the cache in the authentication section of the security realm, in other words authentication=ldap/ . Caches in the authorization section can also be configured in a similar manner by updating the path of the command. Management CLI Command for Enabling a Cache This commands adds a by-access-time cache for authentication with an eviction time of 300 seconds (5 minutes) and a maximum cache size of 100 items. In addition, failed searches will be cached. Alternatively, a by-search-time cache could also be configured: 5.4.2.3. Inspecting an Existing Cache Management CLI Command for Inspecting an Existing Cache The include-runtime attribute adds cache-size , which displays the current number of items in the cache. It is 1 in the above output. 5.4.2.4. Testing an Existing Cache's Contents Management CLI Command for Testing an Existing Cache's Contents This shows that an entry for TestUserOne exists the in the cache. 5.4.2.5. Flushing a Cache You can flushing a single item from a cache, or flush the entire cache. Management CLI Command for Flushing a Single Item Management CLI Command for Flushing an Entire Cache 5.4.2.6. Removing a Cache Management CLI Command for Removing a Cache

Commands:
/subsystem=elytron/dir-context=exampleDC:add(url="ldap://127.0.0.1:10389",principal="uid=admin,ou=system",credential-reference={clear-text="secret"}) /subsystem=elytron/ldap-realm=exampleLR:add(dir-context=exampleDC,identity-mapping={search-base-dn="ou=Users,dc=wildfly,dc=org",rdn-identifier="uid",user-password-mapper={from="userPassword"},attribute-mapping=[{filter-base-dn="ou=Roles,dc=wildfly,dc=org",filter="(&(objectClass=groupOfNames)(member={0}))",from="cn",to="Roles"}]}) /subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles) /subsystem=elytron/security-domain=exampleLdapSD:add(realms=[{realm=exampleLR,role-decoder=from-roles-attribute}],default-realm=exampleLR,permission-mapper=default-permission-mapper) /subsystem=elytron/http-authentication-factory=example-ldap-http-auth:add(http-server-mechanism-factory=global,security-domain=exampleLdapSD,mechanism-configurations=[{mechanism-name=BASIC,mechanism-realm-configurations=[{realm-name=exampleApplicationDomain}]}]) /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=example-ldap-http-auth) reload
/core-service=management/ldap-connection=ldap-connection/:add(search-credential=myPass,url=ldap://127.0.0.1:389,search-dn="cn=search,dc=acme,dc=com") reload
/core-service=management/security-realm=ldap-security-realm:add /core-service=management/security-realm=ldap-security-realm/authentication=ldap:add(connection="ldap-connection", base-dn="cn=users,dc=acme,dc=com",username-attribute="sambaAccountName") reload
/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value="ldap-security-realm")
/core-service=management/ldap-connection=ldap-connection/:add(search-credential=myPass, url=ldaps://LDAP_HOST:LDAP_PORT, search-dn="cn=search,dc=acme,dc=com")
/core-service=management/ldap-connection=ldap-connection:write-attribute(name=security-realm,value="CertificateRealm") reload
/core-service=management/security-realm=ldap-security-realm:add batch /core-service=management/security-realm=ldap-security-realm/authorization=ldap:add(connection=ldap-connection) /core-service=management/security-realm=ldap-security-realm/authorization=ldap/group-search=principal-to-group:add(group-attribute="memberOf",iterative=true,group-dn-attribute="dn", group-name="SIMPLE",group-name-attribute="cn") run-batch
/core-service=management/security-realm=ldap-security-realm:add batch /core-service=management/security-realm=ldap-security-realm/authorization=ldap:add(connection=ldap-connection) /core-service=management/security-realm=ldap-security-realm/authorization=ldap/group-search=group-to-principal:add(iterative=true, group-dn-attribute="dn", group-name="SIMPLE", group-name-attribute="uid", base-dn="ou=groups,dc=group-to-principal,dc=example,dc=org", principal-attribute="uniqueMember", search-by="DISTINGUISHED_NAME") run-batch
/core-service=management/security-realm=ldap-security-realm:add batch /core-service=management/security-realm=ldap-security-realm/authorization=ldap:add(connection=ldap-connection) /core-service=management/security-realm=ldap-security-realm/authorization=ldap/group-search=group-to-principal:add(iterative=true, group-dn-attribute="dn", group-name="SIMPLE", group-name-attribute="uid", base-dn="ou=groups,dc=group-to-principal,dc=example,dc=org", principal-attribute="uniqueMember", search-by="DISTINGUISHED_NAME") /core-service=management/security-realm=ldap-security-realm/authorization=ldap/username-to-dn=username-is-dn:add(force=false) run-batch
/core-service=management/security-realm=ldap-security-realm:add batch /core-service=management/security-realm=ldap-security-realm/authorization=ldap:add(connection=ldap-connection) /core-service=management/security-realm=ldap-security-realm/authorization=ldap/group-search=group-to-principal:add(iterative=true, group-dn-attribute="dn", group-name="SIMPLE", group-name-attribute="uid", base-dn="ou=groups,dc=group-to-principal,dc=example,dc=org", principal-attribute="uniqueMember", search-by="DISTINGUISHED_NAME") /core-service=management/security-realm=ldap-security-realm/authorization=ldap/username-to-dn=username-filter:add(force=false, base-dn="dc=people,dc=harold,dc=example,dc=com", recursive="false", attribute="sn", user-dn-attribute="dn") run-batch
/core-service=management/security-realm=ldap-security-realm:add batch /core-service=management/security-realm=ldap-security-realm/authorization=ldap:add(connection=ldap-connection) /core-service=management/security-realm=ldap-security-realm/authorization=ldap/group-search=group-to-principal:add(iterative=true, group-dn-attribute="dn", group-name="SIMPLE", group-name-attribute="uid", base-dn="ou=groups,dc=group-to-principal,dc=example,dc=org", principal-attribute="uniqueMember", search-by="DISTINGUISHED_NAME") /core-service=management/security-realm=ldap-security-realm/authorization=ldap/username-to-dn=advanced-filter:add(force=true, base-dn="dc=people,dc=harold,dc=example,dc=com", recursive="false", user-dn-attribute="dn",filter="sAMAccountName={0}") run-batch
/core-service=management/access=authorization:read-attribute(name=provider)
{ "outcome" => "success", "result" => "rbac" }
/core-service=management/access=authorization:read-children-names(child-type=role-mapping)
{ "outcome" => "success", "result" => [ "Administrator", "Deployer", "Maintainer", "Monitor", "Operator", "SuperUser" ] }
/core-service=management/access=authorization/role-mapping=Administrator:read-resource(recursive=true)
{ "outcome" => "success", "result" => { "include-all" => false, "exclude" => undefined, "include" => { "user-theboss" => { "name" => "theboss", "realm" => undefined, "type" => "USER" }, "user-harold" => { "name" => "harold", "realm" => undefined, "type" => "USER" }, "group-SysOps" => { "name" => "SysOps", "realm" => undefined, "type" => "GROUP" } } } }
/core-service=management/access=authorization/role-mapping=Auditor:read-resource()
{ "outcome" => "failed", "failure-description" => "WFLYCTL0216: Management resource '[ (\"core-service\" => \"management\"), (\"access\" => \"authorization\"), (\"role-mapping\" => \"Auditor\") ]' not found" }
/core-service=management/access=authorization/role-mapping=Auditor:add()
{ "outcome" => "success" }
/core-service=management/access=authorization/role-mapping=Auditor:read-resource()
{ "outcome" => "success", "result" => { "include-all" => false, "exclude" => undefined, "include" => undefined } }
/core-service=management/access=authorization/role-mapping=Auditor/include=group-GroupToInclude:add(name=GroupToInclude, type=GROUP)
/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-GroupToExclude:add(name=GroupToExclude, type=GROUP)
/core-service=management/access=authorization/role-mapping=Auditor:read-resource(recursive=true)
{ "outcome" => "success", "result" => { "include-all" => false, "exclude" => { "group-GroupToExclude" => { "name" => "GroupToExclude", "realm" => undefined, "type" => "GROUP" } }, "include" => { "group-GroupToInclude" => { "name" => "GroupToInclude", "realm" => undefined, "type" => "GROUP" } } } }
/core-service=management/access=authorization/role-mapping=Auditor/include=group-GroupToInclude:remove
/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-GroupToExclude:remove
"core-service" : { "management" : { "security-realm" : { "LDAPRealm" : { "authentication" : { "ldap" : { "allow-empty-passwords" : false, "base-dn" : "...", "connection" : "MyLdapConnection", "recursive" : false, "user-dn" : "dn", "username-attribute" : "uid", "cache" : null } }, "authorization" : { "ldap" : { "connection" : "MyLdapConnection", "group-search" : { "group-to-principal" : { "base-dn" : "...", "group-dn-attribute" : "dn", "group-name" : "SIMPLE", "group-name-attribute" : "uid", "iterative" : true, "principal-attribute" : "uniqueMember", "search-by" : "DISTINGUISHED_NAME", "cache" : null } }, "username-to-dn" : { "username-filter" : { "attribute" : "uid", "base-dn" : "...", "force" : false, "recursive" : false, "user-dn-attribute" : "dn", "cache" : null } } } }, } } } }
/core-service=management/security-realm=LDAPRealm:read-resource(recursive=true)
{ "outcome" => "success", "result" => { "map-groups-to-roles" => true, "authentication" => { "ldap" => { "advanced-filter" => undefined, "allow-empty-passwords" => false, "base-dn" => "dc=example,dc=com", "connection" => "ldapConnection", "recursive" => true, "user-dn" => "dn", "username-attribute" => "uid", "cache" => undefined } }, "authorization" => { "ldap" => { "connection" => "ldapConnection", "group-search" => { "principal-to-group" => { "group-attribute" => "description", "group-dn-attribute" => "dn", "group-name" => "SIMPLE", "group-name-attribute" => "cn", "iterative" => false, "prefer-original-connection" => true, "skip-missing-groups" => false, "cache" => undefined } }, "username-to-dn" => { "username-filter" => { "attribute" => "uid", "base-dn" => "ou=Users,dc=jboss,dc=org", "force" => true, "recursive" => false, "user-dn-attribute" => "dn", "cache" => undefined } } } }, "plug-in" => undefined, "server-identity" => undefined } }
/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:add(eviction-time=300, cache-failures=true, max-cache-size=100)
/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-search-time:add(eviction-time=300, cache-failures=true, max-cache-size=100)
/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:read-resource(include-runtime=true) { "outcome" => "success", "result" => { "cache-failures" => true, "cache-size" => 1, "eviction-time" => 300, "max-cache-size" => 100 } }
/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:contains(name=TestUserOne) { "outcome" => "success", "result" => true }
/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:flush-cache(name=TestUserOne)
/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:flush-cache()
/core-service=management/security-realm=LDAPRealm/authentication=ldap/cache=by-access-time:remove() reload