-
Language:
English
-
Language:
English
Chapter 2. Elytron Subsystem
2.1. Configure Authentication with a Filesystem-Based Identity Store
Configure a
filesystem-realm
in JBoss EAP:Importantfilesystem-realm
is provided as Technology Preview only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.See Technology Preview Features Support Scope on the Red Hat Customer Portal for information about the support scope for Technology Preview features.
/subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir)
If your directory is located outside of
jboss.server.config.dir
, then you need to change thepath
andrelative-to
values appropriately.Add a user:
When using the
filesystem-realm
, you can add users using the management CLI./subsystem=elytron/filesystem-realm=exampleFsRealm:add-identity(identity=user1) /subsystem=elytron/filesystem-realm=exampleFsRealm:set-password(identity=user1, clear={password="password123"}) /subsystem=elytron/filesystem-realm=exampleFsRealm:add-identity-attribute(identity=user1, name=Roles, value=["Admin","Guest"])
Add a
simple-role-decoder
:/subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles)
This
simple-role-decoder
decodes a principal’s roles from theRoles
attribute. You can change this value if your roles are in a different attribute.Configure a
security-domain
:/subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm,role-decoder=from-roles-attribute}],default-realm=exampleFsRealm,permission-mapper=default-permission-mapper)
Configure an
application-security-domain
in theundertow
subsystem:/subsystem=undertow/application-security-domain=exampleApplicationDomain:add(security-domain=exampleFsSD)
NoteAn
application-security-domain
in theundertow
subsystem can be configured using the management console by navigating to Configuration → Subsystems → Web (Undertow) → Application Security Domain.Configure your application’s
web.xml
andjboss-web.xml
:Your application’s
web.xml
andjboss-web.xml
must be updated to use theapplication-security-domain
you configured in JBoss EAP. An example of this is available in Configure Web Applications to Use Elytron or Legacy Security for Authentication.
Your application is now using a file system-based identity store for authentication.
2.2. Configure Authentication with a Properties File-Based Identity Store
Create properties files:
You must create two properties files: one that maps users to passwords and another that maps users to roles. Usually, these files are located in the
jboss.server.config.dir
directory and follow the naming convention*-users.properties
and*-roles.properties
, but other locations and names can be used. The*-users.properties
file must also contain a reference to theproperties-realm
, which you will create in the next step:#$REALM_NAME=YOUR_PROPERTIES_REALM_NAME$
Example user to password file: example-users.properties
#$REALM_NAME=examplePropRealm$ user1=password123 user2=password123
Example user to roles file: example-roles.properties
user1=Admin user2=Guest
Configure a
properties-realm
in JBoss EAP:/subsystem=elytron/properties-realm=examplePropRealm:add(groups-attribute=groups,groups-properties={path=example-roles.properties,relative-to=jboss.server.config.dir},users-properties={path=example-users.properties,relative-to=jboss.server.config.dir,plain-text=true})
The name of the
properties-realm
isexamplePropRealm
, which is used in the previous step in theexample-users.properties
file. Also, if your properties files are located outside ofjboss.server.config.dir
, then you must change thepath
andrelative-to
values appropriately.Configure a
security-domain
:/subsystem=elytron/security-domain=exampleSD:add(realms=[{realm=examplePropRealm,role-decoder=groups-to-roles}],default-realm=examplePropRealm,permission-mapper=default-permission-mapper)
Configure an
application-security-domain
in theundertow
subsystem:/subsystem=undertow/application-security-domain=exampleApplicationDomain:add(security-domain=exampleSD)
NoteAn
application-security-domain
in theundertow
subsystem can be configured using the management console by navigating to Configuration → Subsystems → Web (Undertow) → Application Security Domain.Configure your application’s
web.xml
andjboss-web.xml
:Your application’s
web.xml
andjboss-web.xml
must be updated to use theapplication-security-domain
you configured in JBoss EAP. An example of this is available in Configure Web Applications to Use Elytron or Legacy Security for Authentication.
Your application is now using a properties file-based identity store for authentication.
The properties files are only read when the server starts. Any users added after server startup, either manually or by using an add-user
script, requires a server reload. This reload is accomplished by running the reload
command from the management CLI.
reload
2.3. Configure Authentication with a Database-Based Identity Store
Determine your database format for usernames, passwords, and roles:
To set up authentication using a database for an identity store, you need to determine how your usernames, passwords, and roles are stored in that database. In this example, we are using a single table with the following sample data:
username password roles user1
password123
Admin
user2
password123
Guest
Configure a datasource:
To connect to a database from JBoss EAP, you must have the appropriate database driver deployed, as well as a datasource configured. This example shows deploying the driver for PostgreSQL and configuring a datasource in JBoss EAP:
deploy /path/to/postgresql-9.4.1210.jar data-source add --name=examplePostgresDS --jndi-name=java:jboss/examplePostgresDS --driver-name=postgresql-9.4.1210.jar --connection-url=jdbc:postgresql://localhost:5432/postgresdb --user-name=postgresAdmin --password=mysecretpassword
Configure a
jdbc-realm
in JBoss EAP:/subsystem=elytron/jdbc-realm=exampleDbRealm:add(principal-query=[{sql="SELECT password,roles FROM eap_users WHERE username=?",data-source=examplePostgresDS,clear-password-mapper={password-index=1},attribute-mapping=[{index=2,to=groups}]}])
NoteThe above example shows how to obtain passwords and roles from a single
principal-query
. You can also create additionalprincipal-query
withattribute-mapping
attributes if you require multiple queries to obtain roles or additional authentication or authorization information.For a list of supported password mappers, see Password Mappers.
Configure a
security-domain
:/subsystem=elytron/security-domain=exampleDbSD:add(realms=[{realm=exampleDbRealm,role-decoder=groups-to-roles}],default-realm=exampleDbRealm,permission-mapper=default-permission-mapper)
Configure an
application-security-domain
in theundertow
subsystem:/subsystem=undertow/application-security-domain=exampleApplicationDomain:add(security-domain=exampleDbSD)
NoteAn
application-security-domain
in theundertow
subsystem can be configured using the management console by navigating to Configuration → Subsystems → Web (Undertow) → Application Security Domain.Configure your application’s
web.xml
andjboss-web.xml
:Your application’s
web.xml
andjboss-web.xml
must be updated to use theapplication-security-domain
you configured in JBoss EAP. An example of this is available in Configure Web Applications to Use Elytron or Legacy Security for Authentication.
2.4. Configure Authentication with an LDAP-Based Identity Store
Determine your LDAP format for usernames, passwords, and roles:
To set up authentication using an LDAP server for an identity store, you need to determine how your usernames, passwords, and roles are stored. In this example, we are using the following structure:
dn: dc=wildfly,dc=org dc: wildfly objectClass: top objectClass: domain dn: ou=Users,dc=wildfly,dc=org objectClass: organizationalUnit objectClass: top ou: Users dn: uid=jsmith,ou=Users,dc=wildfly,dc=org objectClass: top objectClass: person objectClass: inetOrgPerson cn: John Smith sn: smith uid: jsmith userPassword: password123 dn: ou=Roles,dc=wildfly,dc=org objectclass: top objectclass: organizationalUnit ou: Roles dn: cn=Admin,ou=Roles,dc=wildfly,dc=org objectClass: top objectClass: groupOfNames cn: Admin member: uid=jsmith,ou=Users,dc=wildfly,dc=org
Configure a
dir-context
:To connect to the LDAP server from JBoss EAP, you need to configure a
dir-context
that provides the URL as well as the principal used to connect to the server./subsystem=elytron/dir-context=exampleDC:add(url="ldap://127.0.0.1:10389",principal="uid=admin,ou=system",credential-reference={clear-text="secret"})
NoteIt is not possible to use a JMX
ObjectName
to decrypt the LDAP credentials. Instead, credentials can be secured by using a Credential Store as discussed in How to Configure Server Security for JBoss EAP.Configure an
ldap-realm
in JBoss EAP:/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"}]})
WarningIf any referenced LDAP servers contain a loop in referrals, it can result in a
java.lang.OutOfMemoryError
error on the JBoss EAP server.Add a
simple-role-decoder
:/subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles)
Configure a
security-domain
:/subsystem=elytron/security-domain=exampleLdapSD:add(realms=[{realm=exampleLR,role-decoder=from-roles-attribute}],default-realm=exampleLR,permission-mapper=default-permission-mapper)
Configure an
application-security-domain
in theundertow
subsystem:/subsystem=undertow/application-security-domain=exampleApplicationDomain:add(security-domain=exampleLdapSD)
NoteAn
application-security-domain
in theundertow
subsystem can be configured using the management console by navigating to Configuration → Subsystems → Web (Undertow) → Application Security Domain.Configure your application’s
web.xml
andjboss-web.xml
:Your application’s
web.xml
andjboss-web.xml
must be updated to use theapplication-security-domain
you configured in JBoss EAP. An example of this is available in Configure Web Applications to Use Elytron or Legacy Security for Authentication.
In cases where the elytron
subsystem uses an LDAP server to perform authentication, JBoss EAP will return a 500
, or internal server error, error code if that LDAP server is unreachable. This behavior differs from previous versions of JBoss EAP using the legacy security
subsystem, which returned a 401
, or unauthorized, error code under the same conditions.
2.5. Configure Authentication with Certificates
Before you can set up certificate-based authentication, you must have two-way SSL configured. More details on configuring two-way SSL can be found in the Enable Two-way SSL/TLS for Applications using the Elytron Subsystem section of the How to Configure Server Security guide.
Configure a
key-store-realm
./subsystem=elytron/key-store-realm=ksRealm:add(key-store=twoWayTS)
You must configure this realm with a truststore that contains the client’s certificate. The authentication process uses the same certificate presented by the client during the two-way SSL handshake.
Create a decoder.
You need to create a
x500-attribute-principal-decoder
to decode the principal you get from your certificate. The below example will decode the principal based on the firstCN
value./subsystem=elytron/x500-attribute-principal-decoder=CNDecoder:add(oid="2.5.4.3",maximum-segments=1)
For example, if the full
DN
wasCN=client,CN=client-certificate,DC=example,DC=jboss,DC=org
,CNDecoder
would decode the principal asclient
. This decoded principal is used as thealias
value to lookup a certificate in the truststore configured inksRealm
.ImportantThe decoded principal MUST be the
alias
value you set in your server’s truststore for the client’s certificate.- Optionally, you can configure an evidence decoder using a subject alternative name extension to use a subject alternative name as the principal. For more information, see Configuring Evidence Decoder for X.509 Certificate with Subject Alternative Name Extension in the How to Configure Server Security guide.
Add a
constant-role-mapper
for assigning roles.This is example uses a
constant-role-mapper
to assign roles to a principal fromksRealm
, but you can also use other approaches./subsystem=elytron/constant-role-mapper=constantClientCertRole:add(roles=[Admin,Guest])
Configure a
security-domain
./subsystem=elytron/security-domain=exampleCertSD:add(realms=[{realm=ksRealm}],default-realm=ksRealm,permission-mapper=default-permission-mapper,principal-decoder=CNDecoder,role-mapper=constantClientCertRole)
Configure an
application-security-domain
in theundertow
subsystem./subsystem=undertow/application-security-domain=exampleApplicationDomain:add(security-domain=exampleCertSD)
NoteAn
application-security-domain
in theundertow
subsystem can be configured using the management console by navigating to Configuration → Subsystems → Web (Undertow) → Application Security Domain.Update
server-ssl-context
./subsystem=elytron/server-ssl-context=twoWaySSC:write-attribute(name=security-domain,value=exampleCertSD) /subsystem=elytron/server-ssl-context=twoWaySSC:write-attribute(name=authentication-optional, value=true) reload
Configure your application’s
web.xml
andjboss-web.xml
.Your application’s
web.xml
andjboss-web.xml
must be updated to use theapplication-security-domain
you configured in JBoss EAP. An example of this is available in Configure Web Applications to Use Elytron or Legacy Security for Authentication.In addition, you need to update your
web.xml
to useCLIENT-CERT
as its authentication method.<login-config> <auth-method>CLIENT-CERT</auth-method> <realm-name>exampleApplicationDomain</realm-name> </login-config>
2.6. Configure Authentication and Authorization Using Multiple Identity Stores
If you store attributes of an identity across different identity stores, then use an aggregate-realm
to load the identity attributes into a single security realm for authentication and authorization.
2.6.1. Aggregate Realm in Elytron
With an aggregate-realm
, you can use one security realm for authentication and another security realm, or an aggregation of multiple security realms, for authorization in Elytron. For example, you can configure an aggregate realm to use a properties realm for authentication and a JDBC realm for authorization.
In an aggregate realm configured to aggregate multiple authorization realms, an identity is created as follows:
- Attribute values from each security realm configured for authorization are loaded.
- If an attribute is defined in more than one authorization realm, the value of the first occurrence of the attribute is used.
The following example illustrates how an identity is created when multiple authorization realms contain definitions for the same identity attribute.
Example
Aggregate realm configuration:
authentication-realm=properties-realm, authorization-realms=[jdbc-realm,ldap-realm]
Attribute values obtained from the JDBC realm:
e-mail: user@example.com groups: Supervisor, User
Attribute values obtained from the ldap realm:
e-mail: administrator@example.com phone: 0000 0000 0000
Resulting identity obtained from the aggregate realm:
e-mail: user@example.com groups: Supervisor, User phone: 0000 0000 0000
In the example, the attribute e-mail
is defined in both the authorization realms. The value defined in JDBC realm gets used for the attribute e-mail
in the resulting aggregate realm because the aggregate realm was configured to aggregate the authorization realms as: authorization-realms=[jdbc-realm,ldap-realm]
.
2.6.2. Configuring Authentication and Authorization Using an Aggregate Realm
To configure authentication and authorization using an aggregate realm, create an aggregate realm, and configure a security domain and an application security domain to use the aggregate realm.
Prerequisites
The security realms to be aggregated are configured.
For information about configuring security realms, see Elytron Subsystem in the How to Configure Identity Management guide.
A role decoder to be used in the security domain is configured.
For information about role decoders, see Create an Elytron Role Decoder in the How to Configure Server Security guide.
Procedure
Create an aggregate realm:
To create an aggregate realm with one authorization realm:
/subsystem=elytron/aggregate-realm=exampleAggregateRealm:add(authentication-realm=__SECURITY_REALM_FOR_AUTHENTICATION__, authorization-realm=__SECURITY_REALM_FOR_AUTHORIZATION__)
To create an aggregate realm with multiple authorization realms:
/subsystem=elytron/aggregate-realm=exampleAggregateRealm:add(authentication-realm=__SECURITY_REALM_FOR_AUTHENTICATION__, authorization-realms=[__SECURITY_REALM_FOR_AUTHORIZATION_1__,__SECURITY_REALM_FOR_AUTHORIZATION_2__,...,__SECURITY_REALM_FOR_AUTHORIZATION_N__])
Configure a
security-domain
:/subsystem=elytron/security-domain=exampleAggregateRealmSD:add(realms=[{realm=exampleAggregateRealm,role-decoder=__ROLE-DECODER__}],default-realm=exampleAggregateRealm,permission-mapper=default-permission-mapper)
Configure an
application-security-domain
in theundertow
subsystem:/subsystem=undertow/application-security-domain=exampleAggregareRealmApplicationDomain:add(security-domain=exampleAggregateRealmSD)
Configure your application’s
web.xml
andjboss-web.xml
:Your application’s
web.xml
andjboss-web.xml
must be updated to use theapplication-security-domain
you configured in JBoss EAP. An example of this is available in Configure Web Applications to Use Elytron or Legacy Security for Authentication.
2.6.3. Example Aggregate Realms
Example aggregate realm with a single authorizarion realm
In this example, a properties-realm
is used for authentication and a jdbc-realm
is used for authorization.
You must preconfigure the following realms:
-
properties-realm
named examplPropertiesRealm -
jdbc-realm
named exampleJdbcRealm
Issuing the following command creates an aggregate realm:
/subsystem=elytron/aggregate-realm:exampleSimpleAggregateRealm:add(authentication-realm=examplPropertiesRealm,authorization-realm=exampleJdbcRealm)
Example aggregate realm with two authorization realms
In this example, properties-realm
is used for authentication and an aggregation of ldap-realm
and jdbc-realm
is used for authorization.
You must preconfigure the following realms:
-
properties-realm
named examplPropertiesRealm -
jdbc-realm
named exampleJdbcRealm -
ldap-realm
named exampleLdapRealm
Issuing the following command creates an aggregate realm:
/subsystem=elytron/aggregate-realm:exampleSimpleAggregateRealm:add(authentication-realm=examplPropertiesRealm,authorization-realms=[exampleJdbcRealm,exampleLdapRealm])
2.7. Override an Application’s Authentication Configuration
You can override the authentication configuration of an application with one configured in JBoss EAP. To do this, use the override-deployment-configuration
property in the application-security-domain
section of the undertow
subsystem:
/subsystem=undertow/application-security-domain=exampleApplicationDomain:write-attribute(name=override-deployment-config,value=true)
An application-security-domain
in the undertow
subsystem can be configured using the management console by navigating to Configuration → Subsystems → Web (Undertow) → Application Security Domain.
For example, an application is configured to use FORM
authentication with the exampleApplicationDomain
in its jboss-web.xml
.
Example jboss-web.xml
<login-config> <auth-method>FORM</auth-method> <realm-name>exampleApplicationDomain</realm-name> </login-config>
By enabling override-deployment-configuration
, you can create a new http-authentication-factory
that specifies a different authentication mechanism, such as BASIC
or DIGEST
.
Example http-authentication-factory
/subsystem=elytron/http-authentication-factory=exampleHttpAuth:read-resource() { "outcome" => "success", "result" => { "http-server-mechanism-factory" => "global", "mechanism-configurations" => [{ "mechanism-name" => "BASIC", "mechanism-realm-configurations" => [{"realm-name" => "exampleApplicationDomain"}] }], "security-domain" => "exampleSD" } }
This will override the authentication mechanism defined in the application’s jboss-web.xml
and attempt to authenticate a user using BASIC
instead of FORM
.
2.8. Set Up Caching for Security Realms
Elytron provides a caching-realm
which allows you to cache the results of a credential lookup from a security realm. For example, you could use this to configure a cache for credentials coming from LDAP or a database to increase performance for frequently queried users.
The caching-realm
caches the PasswordCredential
credential using a LRU or Least Recently Used caching strategy, in which the least accessed entries are discarded when maximum number of entries is reached.
You can use a caching-realm
with the following security realms:
-
filesystem-realm
-
jdbc-realm
-
ldap-realm
- a custom security realm
filesystem-realm
is provided as Technology Preview only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
See Technology Preview Features Support Scope on the Red Hat Customer Portal for information about the support scope for Technology Preview features.
If you make changes to your credential source outside of JBoss EAP, those changes are only propagated to a JBoss EAP caching realm if the underlying security realm supports listening. In particular, an ldap-realm
supports listening, however filtered attributes, such as roles
, inside the ldap-realm
do not.
To ensure that your caching realm has a correct cache of user data, it is recommended that you modify your user attributes through the caching realm rather than at your credential source. Alternatively, you can clear the cache.
Making user changes through a caching realm is provided as Technology Preview only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
See Technology Preview Features Support Scope on the Red Hat Customer Portal for information about the support scope for Technology Preview features.
To configure and use a caching-realm
:
Create an existing security realm.
You need an existing security realm to use with a
caching-realm
. For example, you could create afilesystem-realm
similar to the steps in Configure Authentication with a Filesystem-Based Identity Store.Example filesystem-realm
/subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users, relative-to=jboss.server.config.dir) /subsystem=elytron/filesystem-realm=exampleFsRealm:add-identity(identity=user1) /subsystem=elytron/filesystem-realm=exampleFsRealm:set-password(identity=user1, clear={password="password123"}) /subsystem=elytron/filesystem-realm=exampleFsRealm:add-identity-attribute(identity=user1,name=Roles,value=["Admin","Guest"]) /subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles)
Create a
caching-realm
.Once you have an existing realm you want to cache, create a
caching-realm
that references it.Example caching-realm that Uses exampleFsRealm
/subsystem=elytron/caching-realm=exampleCacheRealm:add(realm=exampleFsRealm)
Use the
caching-realm
.After you create the
caching-realm
, you can then use it in your security configuration just as you would any other security realm. For example, you could use it in the same place you would use afilesystem-realm
in Configure Authentication with a Filesystem-Based Identity Store.Example Configuration Using the caching-realm
/subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleCacheRealm, role-decoder=from-roles-attribute}], default-realm=exampleCacheRealm, permission-mapper=default-permission-mapper) /subsystem=elytron/http-authentication-factory=example-fs-http-auth:add(http-server-mechanism-factory=global, security-domain=exampleFsSD, mechanism-configurations=[{mechanism-name=BASIC, mechanism-realm-configurations=[{realm-name=exampleApplicationDomain}]}])
You can control the cache size as well as item expiration by using maximum-entries
and maximum-age
attributes of the caching-realm
. For more details on those attributes, see the Elytron Subsystem Components Reference section in How to Configure Server Security.
Clear a caching-realm
Cache
You can clear an existing cache by using the clear-cache
command. Clearing a cache forces it to repopulate using the latest data from the security realm.
/subsystem=elytron/caching-realm=exampleCacheRealm:clear-cache
2.9. Configure Applications to use Container-managed Single Sign-on
You can configure JBoss EAP to use container-managed single sign-on for applications using the Elytron FORM
authentication method. This allows users to authenticate once and access other resources secured by the FORM
authentication method without having to reauthenticate.
The related single sign-on session is invalidated when:
- there are no active local sessions left.
- logging out from an application.
You can use single sign-on across applications deployed on different JBoss EAP instances as long as these instances are in a cluster.
Create a
key-store
.A
key-store
is necessary in order to configure a secure communication channel between the different servers participating in the SSO. This channel is used to exchange messages about events that occur when single sign-on sessions are created or destroyed, during log in and log out respectively.To create a
key-store
in theelytron
subsystem, first create a Java KeyStore as follows:keytool -genkeypair -alias localhost -keyalg RSA -keysize 1024 -validity 365 -keystore keystore.jks -dname "CN=localhost" -keypass secret -storepass secret
Once the
keystore.jks
file is created, execute the following management CLI command to create akey-store
definition in Elytron:/subsystem=elytron/key-store=example-keystore:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS)
Add the security realm.
Create a
FileSystem
realm, an identity store where users are stored in the local file system, using the following management CLI command:/subsystem=elytron/filesystem-realm=example-realm:add(path=/tmp/example-realm)
Use the following management CLI command to create a
security-domain
:/subsystem=elytron/security-domain=example-domain:add(default-realm=example-realm,permission-mapper=default-permission-mapper,realms=[{realm=example-realm,role-decoder=groups-to-roles}]
NoteApplications using SSO should use
HTTP FORM
authentication as they usually need to provide a login page for the users.Create an application security domain in the
undertow
subsystem.NoteIf you already have a
application-security-domain
defined in theundertow
subsystem and just want to use it to enable single sign-on to your applications, you can skip this step./subsystem=undertow/application-security-domain=other:add(security-domain=example-domain)
NoteBy default, if your application does not define any specific security-domain in the
jboss-web.xml
file, the application server will choose one with a nameother
.Update the
undertow
subsystem to enable single sign-on and use the keystore.Single sign-on is enabled to a specific
application-security-domain
definition in theundertow
subsystem. It is important that the servers you are using to deploy the applications are using the same configuration.To enable single sign-on, just change an existing
application-security-domain
in theundertow
subsystem as follows:/subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=example-keystore, key-alias=localhost, domain=localhost, credential-reference={clear-text=secret})
NoteAn
application-security-domain
in theundertow
subsystem can be configured using the management console by navigating to Configuration → Subsystems → Web (Undertow) → Application Security Domain.For more information on the SSO attributes and their definitions, see Reference for Single Sign-on Attributes.
Configure your application’s
web.xml
andjboss-web.xml
files.Your application’s
web.xml
andjboss-web.xml
must be updated to use theapplication-security-domain
you configured in JBoss EAP. An example of this is available in Configure Web Applications to Use Elytron or Legacy Security for Authentication.
JBoss EAP provides out-of-the-box support for clustered and non-clustered SSO using the undertow
and infinispan
subsystems.