Parent: Derek
No access controls to WLST command line (i.e. CyberArk, Port Restrictions, Certificate-Based Auth etc).
The portal uses a hardcoded admin credential with autologin enabled. Anyone who obtains this password — which is not difficult given it is also noted as easily guessable and published on the intranet (audit point 5) — can bypass the portal entirely and connect directly to WebLogic via WLST with full admin rights. The portal enforces role-based access for its own users; that protection is entirely bypassed by a direct WLST connection.
WebLogic Connection Filter. WebLogic has a built-in connection filter (weblogic.security.net.ConnectionFilterImpl) that restricts incoming connections by IP/CIDR, port, and protocol — analogous to Apache httpd Allow/Deny directives. Rules are configured in config.xml and can be reloaded without a restart. This restricts direct WLST access to known admin hosts at the WebLogic level, without requiring network infrastructure changes.
Audit logging. Enable WebLogic audit logging so that any direct access (outside the portal) is recorded.
Remove the hardcoded credential — CyberArk integration. The portal should call CyberArk's Central Credential Provider (AAM) at runtime to obtain the WebLogic service account credential. CyberArk vaults and rotates the credential; the portal never stores it. This eliminates the static password.
Portal authentication. The user authenticates to the portal via AD credentials or a bearer token. The portal uses the CyberArk-issued credential to connect to WebLogic on the user's behalf. WebLogic sees the portal's service account — it does not see the end user identity. The portal is responsible for enforcing what each user can do; WebLogic audit logging records actions against the service account. This is a pragmatic boundary: true per-user identity propagation into WebLogic is possible (via JAAS identity assertion) but is a significantly larger piece of work and is not required to address the immediate finding.