IBM WebSphere Application Server still runs core banking, insurance and government systems, often on estates built a decade ago with administrative security switched on once and never revisited. The risks are familiar: shared administrator logins, LTPA keys that nobody has rotated, TLS settings that predate TLS 1.2, Java 2 security left off, sample applications still deployed, and deserialisation-prone interfaces reachable from networks that should never see them. This guide sets out how identity and access work in WebSphere traditional, how to divide its administrative roles, the machine credentials a cell holds, what to log, and a hardening baseline drawn from IBM's documentation, the DISA STIG for WebSphere Traditional V9.x and the Open Liberty hardening guidance. It is for middleware administrators, platform engineers and security assessors responsible for WebSphere traditional 9.0.5 and Liberty. Java application-level controls are covered in the Java and Spring Security Guide, and the sister product is covered in the Oracle WebLogic Server Hardening Guide.
Key takeaways
- Nothing is enforced until administrative security is on. IBM states that the administrative authorisation policy is only enforced when administrative security is enabled, and the STIG rates "Enable administrative security" as a high-severity finding.
- Split the Administrator, Admin Security Manager and Auditor roles. WebSphere separates who changes configuration, who assigns administrative roles and who controls the security audit subsystem; only an auditor can change auditor assignments.
- LTPA keys are the cell's session-signing secret. The STIG requires manual LTPA key regeneration on a documented schedule, at least annually, with "automatically generate keys" unchecked so rotation is a controlled change.
- Set TLS 1.2 or later on every SSL configuration. The quality of protection setting must be "TLSv1.2 or greater", LDAP must use LDAPS, export ciphers must go and the web server plug-in must use HTTPS only.
- Treat deserialisation as a standing risk. CVE-2015-7450, a code injection flaw through serialised-object interfaces, is in the CISA Known Exploited Vulnerabilities catalogue for WebSphere; keep administrative and RMI/IIOP ports off untrusted networks and patch on IBM's schedule.
How identity and access work in IBM WebSphere
A WebSphere traditional cell (deployment manager, node agents and application servers) has two layers of security. Administrative security protects the administrative console, wsadmin scripting, JMX and inter-process communication, and authenticates administrators against the configured user registry: a federated repository, standalone LDAP, the local operating system or a custom registry. Application security applies Java EE security roles to deployed applications. A cell can also define security domains so that groups of servers use a different registry or settings from the global configuration.
| Component | What it does | Hardening point |
|---|---|---|
| User registry | Authenticates administrators and users | Use LDAP over LDAPS or a federated repository; the STIG requires LDAPS for authentication and authorised LDAP group mappings |
| Primary administrative user | Server identity created when security is enabled | Must log in to change administrative role assignments (other than auditor); vault its password and do not use it for daily work |
| Administrative roles | Control console, wsadmin and JMX actions | Map registry groups, not individual users, as IBM recommends |
| LTPA | Token format for single sign-on between servers and with IBM HTTP Server | Manual key regeneration; SSO requires SSL; HttpOnly cookies |
| CSIv2 and SAS | Authentication for RMI/IIOP between servers and clients | Require SSL and client authentication on inbound transport where clients exist; block from untrusted networks |
| Java 2 security | Restricts what application code can do on the host | Enable it; the STIG rates it high severity and forbids bypassing it |
Open Liberty and WebSphere Liberty follow the same principles with a different shape: configuration lives in server.xml, and IBM's guidance is that Basic and Quick Start Security registries are for development only, never for readiness testing, QA or production. Production Liberty should use LDAP, a federated registry or SSO through SAML, JWT or OpenID Connect, with SSO and LDAP bind passwords in separate include files.
Admin roles and privileged access
| Role | Can do | Assign to |
|---|---|---|
| Monitor | View configuration and server state | Operations, monitoring tools, auditors |
| Operator | Monitor plus start, stop and check servers | Operations staff |
| Configurator | Monitor plus create resources, install and deploy applications, map users and groups to application roles, set Java 2 permissions for applications | Middleware engineers |
| Deployer | Configuration and runtime operations on applications only, not servers or nodes | Release engineers and CI/CD identities |
| Administrator | Operator and configurator plus change the server identity, configure authentication and authorisation, enable or disable administrative and Java 2 security, change the LTPA password and generate keys, customise CSIv2, SAS and SSL | Two or three named platform owners |
| Admin Security Manager | Assign users and groups to administrative roles | A security owner who is not also a daily administrator |
| Auditor | Enable and configure security auditing (event factory, service provider, audit policy, event filters) | Security or compliance staff, separate from administrators |
| iscadmins | Console-only management of users and groups in federated repositories | Identity administrators, if the registry is managed in WebSphere |
- Administrators cannot grant roles alone: mapping users and groups to administrative roles needs the Admin Security Manager role as well, which the Administrator role does not imply. Keep it that way.
- Separate audit from administration: when security auditing is first enabled, the primary administrative user also gets the Auditor role. Remove it and give it to a separate group, so administrators can view but not change audit settings.
- Use fine-grained administrative security in shared cells: authorisation groups let you grant Deployer or Configurator on specific applications or servers rather than the whole cell.
- Review mappings against the security plan: the STIG requires that users in the admin and auditor roles, and LDAP or local groups mapped to roles, are authorised and documented.
- Do not run as root: the STIG requires WebSphere to run as a non-administrative operating system user. Open Liberty's guidance adds that the run-time ID should have only read access to its own configuration, with administrators using sudo to a dedicated owner ID instead of shared logins.
For broader PAM practice around shared middleware accounts, see the Privileged Access Management Guide.
Integrations, API tokens and service accounts
A WebSphere cell is full of non-human credentials, and most of them live in configuration files.
- JAAS J2C authentication data aliases: database, messaging and EIS passwords are stored as authentication aliases in the cell configuration. In traditional WebSphere these are encoded rather than strongly encrypted by default, so anyone who can read the configuration repository can recover them. Restrict file system access to the profile directories, limit who holds Configurator and Administrator, and move credentials to a vault where your release supports it. See the Secrets Management Guide.
- Liberty password encoding: Open Liberty recommends AES encoding (
securityUtility encode --encoding=aes) rather than XOR, noting that an XOR-encoded password is visible to any administrator. Set the key throughwlp.aes.encryption.keyorwlp.password.encryption.keyand keep it out ofserver.xml. - LTPA keys: the LTPA key set signs tokens trusted across the cell and by IBM HTTP Server plug-ins. A stolen key file lets an attacker forge sessions. Regenerate manually on a schedule and after any suspected exposure; in Liberty, delete
ltpa.keysto force regeneration. - Keystores and trust stores: node and cell keystores hold the private keys for inter-process TLS. The STIG requires DoD root CAs in the trust store for DoD systems; elsewhere, trust only the CAs you need and track certificate expiry. See the Machine Identity, PKI and Certificate Lifecycle Guide.
- Scripting and deployment identities: wsadmin scripts in CI/CD pipelines often embed the primary administrative user's password. Give pipelines a Deployer identity scoped by fine-grained administrative security, store its password in the pipeline's secret store, and rotate it.
- Liberty JMX: avoid
localConnector-1.0in production; userestConnector-2.0, and if IBM HTTP Server fronts Liberty, secure access to the/IBMJMXConnectorREST/*and/ibm/api/*paths.
Logging and detection
WebSphere has two log families: JVM logs (SystemOut, SystemErr and trace) and the security auditing subsystem, which must be enabled separately under Security > Security auditing. The STIG expects auditing enabled, event type filters configured, the audit service provider enabled, log failure alerts to administrators and the ISSO, and audit records protected from unauthorised reading, modification and deletion, with encryption and signing of audit logs.
| What to watch | Source | Why it matters |
|---|---|---|
| Administrative role mapping changes | Security audit events, configuration repository checkpoints | New administrators are the main persistence path (MITRE ATT&CK T1098 Account Manipulation) |
| Global security changes (administrative security, Java 2 security, LTPA, SSL settings) | Audit events; automatic repository checkpoints (required by the STIG) | Disabling controls is defence impairment (T1685 Disable or Modify Tools) |
| Application installs and updates | Audit events, deployment manager logs | Malicious application deployment is the WebSphere equivalent of a web shell (T1505.003 Web Shell) |
| Authentication failures to console and wsadmin | Audit events, SystemOut | Password guessing against administrators (T1110 Brute Force) |
| Exploit attempts on public listeners | IBM HTTP Server or WAF logs in front of WebSphere | Deserialisation and other exploits (T1190 Exploit Public-Facing Application) |
| Audit subsystem failure | JVM logs, alerts | The STIG requires alerts on log processing failure |
Forward both families to a SIEM and alert on role mapping changes, security setting changes and application deployments outside change windows. Metrics:
- Cells with administrative security, Java 2 security and auditing enabled (target 100%).
- Days since last LTPA key regeneration per cell (target under 365).
- SSL configurations below TLS 1.2 (target zero).
- Named individuals in Administrator per cell, and shared logins in use (target zero).
- Days behind the latest fix pack and security bulletins per installation.
Hardening baseline
| Area | Setting (console path or file) | Baseline |
|---|---|---|
| Administrative security | Security > Global security > Enable administrative security | Enabled; restart deployment manager and all JVMs |
| Application security | Security > Global security > Enable application security | Enabled; applications deny by default and protect every entry point with roles |
| Java 2 security | Security > Global security > Java 2 security: "Use Java 2 security to restrict application access to local resources" | Enabled, with per-application policies |
| TLS | Security > SSL certificate and key management > SSL configurations > Quality of protection (QoP) settings | Protocol "TLSv1.2 or greater"; remove export ciphers; FIPS 140 approved modules where required |
| LTPA | Security > SSL certificate and key management > Key set groups > Cell LTPAKeySetGroup | "Automatically generate keys" unchecked; documented manual regeneration at least annually |
| Single sign-on | Web and SIP security > Single sign-on | SSL required; HttpOnly cookies |
| Auditing | Security > Security auditing | Enabled with event filters, audit service provider, failure alerts |
| Console session | Administrative console session timeout | Configured to a short value per the security plan |
| Samples and defaults | Installed applications | Remove sample applications |
| Ports | Servers > All servers > Ports; deployment manager and node agent ports | Document every port; only HTTP(S) transport through the outer firewall; administrative, SOAP and RMI/IIOP ports on a management network |
| Liberty | server.xml | <webAppSecurity ssoRequiresSSL="true" httpOnlyCookies="true"/>, <httpOptions removeServerHeader="true"/>, <httpDispatcher enableWelcomePage="false"/>, <config updateTrigger="mbean"/> and dropinsEnabled="false" |
Common default ports in a traditional application server profile are 9060 and 9043 for the administrative console, 8880 for the SOAP connector and 2809 for bootstrap (RMI/IIOP); confirm yours under the Ports panel, because profiles created on the same host take later numbers.
Rollout
- Assess. Run the DISA STIG checks (or the CIS IBM WebSphere benchmark) against each cell and record findings by severity: the STIG for WebSphere Traditional V9.x (V2R1) has 77 findings, 9 of them high.
- Fix identity first. Move to LDAPS or a federated repository, map groups to roles, split Administrator, Admin Security Manager and Auditor, and remove shared logins.
- Test security changes in a non-production cell. Enabling Java 2 security and raising TLS can break applications and older clients; run regression tests and fix policies before production.
- Apply in production per cell. Most global security changes need a restart of the deployment manager and all JVMs; schedule them in a maintenance window, with a configuration checkpoint taken first so you can restore it.
- Roll back from checkpoints. Restore the repository checkpoint and restart if a change breaks service; keep the primary administrative user's credentials vaulted for recovery.
- Patch continuously. Apply fix packs and security bulletins, and track exploited vulnerabilities with the CISA KEV Catalogue Guide.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|---|
| Administrative roles and separation | AC-2, AC-6 | PR.AA-05 | Control 5, Control 6 | A.8.2 Privileged access rights |
| Secure configuration (STIG, Java 2, samples) | CM-6, CM-7 | PR.PS-01 | Control 4 Secure Configuration | A.8.9 Configuration management |
| TLS and LDAPS | SC-8 | PR.DS-02 | Control 3 Data Protection | A.8.24 Use of cryptography |
| Security auditing | AU-2, AU-6 | DE.CM-03, PR.PS-04 | Control 8 Audit Log Management | A.8.15 Logging |
| Patching | SI-2 | ID.RA-01 | Control 7 Continuous Vulnerability Management | A.8.8 Management of technical vulnerabilities |
Common misconfigurations
- Shared primary administrator: one account used by everyone makes audit meaningless and makes offboarding impossible. Map named LDAP groups to roles.
- Administrators who are also auditors: the default after enabling auditing gives the primary administrator the Auditor role, so the people being audited control the audit. Separate them.
- Management ports on the application network: SOAP, RMI/IIOP and console ports reachable from user networks expose deserialisation and credential attacks. Firewall them to a management network.
- LTPA keys never rotated: keys created at install time and copied across environments let a test environment compromise production sessions. Regenerate per environment and on schedule.
- Java 2 security off "for compatibility": a compromised application then has the server's full rights on the host. Enable it and write application policies.
- Passwords in readable configuration: authentication aliases and Liberty XOR-encoded passwords are trivially reversible by anyone with file access. Lock down file permissions and use AES or a vault.
Practitioner checklist
- Enable administrative security, application security and Java 2 security in every cell.
- Use LDAPS or a federated repository and map groups, not users, to administrative roles.
- Separate Administrator, Admin Security Manager and Auditor, and remove the Auditor role from the primary administrator.
- Set every SSL configuration's QoP to TLS 1.2 or greater and remove export ciphers.
- Disable automatic LTPA key generation and regenerate keys manually at least annually.
- Enable security auditing with event filters, failure alerts and protected, signed audit logs.
- Remove sample applications and restrict administrative, SOAP and RMI/IIOP ports to a management network.
- Run WebSphere as a non-administrative OS user with read-only access to its own configuration.
- Assess quarterly against the DISA STIG or CIS benchmark and apply fix packs and security bulletins promptly.
Standards and references
- IBM: WebSphere Application Server Administrative Roles
- DISA: IBM WebSphere Traditional V9.x Security Technical Implementation Guide
- Open Liberty: Security Hardening for Production
- Open Liberty: Server Configuration Security Hardening
- Open Liberty: Network Security Hardening
- IBM Community: Getting Started Securing Your WebSphere Applications
- CISA: Known Exploited Vulnerabilities Catalog
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Java and Spring Security Guide · Oracle WebLogic Server Hardening Guide · Apache Tomcat Hardening Guide · Secrets Management Guide