IBM Security Verify Access can be used to integrate on-premises user registries (eg. LDAP, Active Directory) with applications
running on JBoss or Wildfly application servers. The web reverse proxy component is used to provide and enforce access to
downstream server's junctioned by WebSEAL. Identity information provided by Verify Access is then consumed by the Elytron
subsystem which passes on the identity to java web applications. Customised or complex access policies can be implemented
using the Advanced Access Control component of Verify Access.
This integration assumes you are familiar with a number IBM Security Verify Access configuration options. At a minimum
you should be able to:
- Create WebSEAL instances and junctions
- Modify the WebSEAL configuration file
- Manage the runtime server's SSL database
This guide assumes that you have Verify Access (hardware, virtual machine or containers) deployed and the runtime server and user registry configured. Some additional configuration may be required if a Federated user registry (eg. Active Directory) or a Federated Identity (eg. OIDC or SAML) are used.
You should also have a JBoss or Wildfly server deployed and configured to use the Json Web Token (JWT) token-realm feature of the Elytron security subsystem. Instructions for configuring JBoss are detailed in this guide. Identity is supplied via a JWT constructed from the available user attributes. This guide assumes you are familiar with the associated PKI needed to verify and (if required) decrypt JWTs.
Where possible it is recommended to secure the WebSEAL junction the downstream JBoss server using SSL. By default WebSEAL instances use the
pdsrv SSL certificate database. To enable SSL communication a certificate which is part of the X509 trust chain from the JBoss SSL handshake must be imported into the SSL certificate database used by your WebSEAL instance.
To enable mutual verification a certificate which is part of the X509 trust chain from the WebSEAL handshake must be imported into the JBoss SSL keystore. The default keystore type in JBoss/Wildfly is set to
JKS however this guide uses
PKCS12. The default SSL keystore
standalone.xml elements should be updated with the following:
<subsystem xmlns="urn:wildfly:elytron:14.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
<file path="application.keystore" relative-to="jboss.server.config.dir"/>
A WebSEAL instance is used to supply and enforce authentication requirements. At a minimum you will need to create/modify a WebSEAL instance with a junction to the target JBoss server and add the JWT configuration stanza configured to match the claims configured for the Elytron subsystem.
Create a mutual junction to the JBoss or Wildfly server. This guide uses a standard junction, however a transparent junction can be used if the downstream server must be able to redirect using relative paths. The junction should be configured to use SSL connection with no other additional configuration is required.
This can also be done using the
pdadmin CLI tool:
[user@workstation ~]$ ssh [email protected]
Warning: Permanently added '192.168.42.101' (ED25519) to the list of known hosts.
([email protected]) Password: *****
Welcome to the IBM Security Verify Access appliance
Enter "help" for a list of available commands
my.isva.appliance> isam admin
pdadmin> server task <instance_name>-webseald-<host_name_or_address> create –t mutual -h target.integration.server -p 9080 -P 9443 /wildfly-sso-demo
Created junction at /wildfly-sso-demo
To configure WebSEAL to supply a JWT, a
[jwt:<junction name>] stanza is added to the WebSEAL configuration file. This stanza contains the attribute mapping to be used as well as any cryptographic configuration required. The demo integration uses the self signed certificate created in the
pdsrv keystore (WebSEAL default keystore) to sign JWTs. In a production environment this should be replaced with appropriate PKI. The HTTP header used must be of the form
Authorization: Bearer %TOKEN% as the Elytron subsystem does not allow for this to be changed.
key-label = WebSEAL-Test-Only
claim = text::www.ibm.com::iss
claim = attr::AZN_*
claim = attr::AZN_CRED_PRINCIPAL_NAME::sub
include-empty-claims = false
hdr-name = Authorization
hdr-format = Bearer %TOKEN%
lifetime = 0
renewal-window = 15
Any additional Access Control Lists (ACLs) and Protected Object Policies (POPs) required for the junctioned resource should also be created here. ACLs and POPs are used to define additional business logic required to enforce additional security requirements to access web resources. Out of the box step-up authentication, provided by the Advanced Access Control module is a simple to use example of the additional authentication which can be implemented using IBM Security Verify Access.
Updated 6 months ago