JBoss Enterprise Application Platform 8 Version
8.1 Security Target
Version: 2.0
Status: Released
Last Update: 2026-01-30
Classiﬁcation: Public
Authors: Alejandro Masino
Red Hat, Inc.
JBoss EAP 8 Security Target
Trademarks
Red Hat and the Red Hat logo are trademarks or registered trademarks of Red Hat, Inc. in the United
States, other countries, or both.
The following terms are trademarks of Oracle, Corp.:
● Java
● Java EE
The following terms are trademarks of the Eclipse Foundation:
● Jakarta
● Jakarta EE®
Legal Notice
This document is provided AS IS with no express or implied warranties. Use the information in this
document at your own risk.
This document may be reproduced or distributed in any form without prior permission provided
the copyright notice is retained on all copies. Modiﬁed versions of this document may be freely
distributed provided that they are clearly identiﬁed as such, and this copyright is included intact.
Revision History
Version Date Author(s) Changes to Previous Revision
2.0 2026-01-30 Alejandro Masino First public version.
Version: 2.0 Classiﬁcation: Public Page 2 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Table of Contents
1 Introduction ....................................................................................................... 8
1.1 Security Target Identiﬁcation ............................................................................................ 8
1.2 TOE Identiﬁcation .............................................................................................................. 8
1.3 TOE Type ........................................................................................................................... 8
1.4 TOE Overview .................................................................................................................... 8
1.4.1 TOE Type .................................................................................................................. 8
1.4.2 Required Non-TOE Hardware and Software ............................................................... 9
1.4.3 Intended Method of Use .......................................................................................... 10
1.4.4 Major Security Features .......................................................................................... 10
1.5 TOE Description ............................................................................................................... 11
1.5.1 Introduction ............................................................................................................. 11
1.5.2 Application Server Deﬁnition ................................................................................... 11
1.5.3 JBoss EAP Structure ................................................................................................ 12
1.5.3.1 Java Security Manager .................................................................................... 15
1.5.4 TOE boundaries ....................................................................................................... 15
1.5.4.1 Physical .......................................................................................................... 15
1.5.4.2 Logical ............................................................................................................ 16
1.5.4.2.1 Evaluated conﬁguration ......................................................................... 17
1.5.4.3 Security Policy Model ..................................................................................... 17
2 CC Conformance Claim ...................................................................................... 19
3 Security Problem Deﬁnition ............................................................................... 20
3.1 Threat Environment ......................................................................................................... 20
3.1.1 Threats countered by the TOE ................................................................................ 20
3.2 Assumptions .................................................................................................................... 21
3.2.1 Environment of use of the TOE ............................................................................... 21
3.2.1.1 Physical .......................................................................................................... 21
3.2.1.2 Personnel ........................................................................................................ 21
3.2.1.3 Connectivity ................................................................................................... 21
3.3 Organizational Security Policies ....................................................................................... 22
4 Security Objectives ........................................................................................... 23
4.1 Objectives for the TOE .................................................................................................... 23
4.2 Objectives for the Operational Environment .................................................................... 23
4.3 Security Objectives Rationale .......................................................................................... 24
4.3.1 Security objectives coverage .................................................................................. 24
4.3.2 Security objectives suﬃciency ................................................................................ 25
5 Extended Components Deﬁnition ....................................................................... 27
5.1 Class FDP: User data protection ...................................................................................... 27
5.1.1 Rollback (FDP_ROL) ................................................................................................. 27
5.1.1.1 FDP_ROL_EXT.2 Automated rollback ............................................................... 27
6 Security Requirements ...................................................................................... 28
6.1 TOE Security Functional Requirements ............................................................................ 28
6.1.1 Jakarta EE Security Mechanisms ............................................................................. 29
Version: 2.0 Classiﬁcation: Public Page 3 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
6.1.1.1 FAU_GEN.1 Audit data generation ................................................................. 29
6.1.1.2 FAU_GEN.2 User identity association ............................................................. 30
6.1.1.3 FDP_ACC.1(HTTP) HTTP Access Control Policy ............................................... 30
6.1.1.4 FDP_ACC.1(EJB) EJB Access Control Policy ..................................................... 30
6.1.1.5 FDP_ACC.1(JMS) JMS Access Control Policy .................................................... 30
6.1.1.6 FDP_ACF.1(HTTP) HTTP Access Control Functions .......................................... 31
6.1.1.7 FDP_ACF.1(EJB) EJB Access Control Functions ................................................ 31
6.1.1.8 FDP_ACF.1(JMS) JMS Access Control Functions ............................................... 32
6.1.1.9 FDP_ROL_EXT.2 Automated rollback .............................................................. 33
6.1.1.10 FIA_ATD.1 User attribute deﬁnition .............................................................. 33
6.1.1.11 FIA_UAU.1 Timing of authentication ............................................................ 33
6.1.1.12 FIA_UID.1 Timing of identiﬁcation ................................................................ 34
6.1.1.13 FIA_USB.1 User-subject binding ................................................................... 34
6.1.1.14 FMT_MSA.1(EJB) Management of object security attributes .......................... 35
6.1.1.15 FMT_MSA.1(JMS) Management of object security attributes ......................... 35
6.1.1.16 FMT_MSA.3(WEB) Static attribute initialisation ............................................ 35
6.1.1.17 FMT_MSA.3(EJB) Static attribute initialisation ............................................... 35
6.1.1.18 FMT_MSA.3(JMS) Static attribute initialization .............................................. 36
6.1.1.19 FMT_MTD.1(ACC) Management of TSF data ................................................. 36
6.1.1.20 FMT_MTD.1(JMS) Management of TSF data .................................................. 36
6.1.1.21 FMT_MTD.1(AUTH) Management of TSF data ............................................... 36
6.1.1.22 FPT_TRC.1 Internal TSF consistency ............................................................ 37
6.1.2 JBoss EAP Management security ............................................................................. 37
6.1.2.1 FDP_ACC.1(RBAC) Role-Based Access Control Policy ..................................... 37
6.1.2.2 FDP_ACF.1(RBAC) Role-Based Access Control Functions ................................ 38
6.1.2.3 FMT_MSA.1(RBAC) Management of object security attributes ........................ 38
6.1.2.4 FMT_MSA.3(RBAC) Static attribute initialization ............................................. 38
6.1.2.5 FMT_SMF.1 Speciﬁcation of management functions ....................................... 39
6.1.2.6 FMT_SMR.2 Security roles ............................................................................. 39
6.2 Security Functional Requirements Rationale .................................................................... 39
6.2.1 Security requirements coverage ............................................................................. 39
6.2.2 Security requirements suﬃciency ........................................................................... 41
6.2.3 Security requirements dependency analysis ........................................................... 43
6.3 Security Assurance Requirements ................................................................................... 45
6.4 Security Assurance Requirements Rationale .................................................................... 46
7 TOE Summary Speciﬁcation ............................................................................... 47
7.1 TOE Security Functionality ............................................................................................... 47
7.1.1 Access Control ........................................................................................................ 47
7.1.2 Role-based Access Control for Management Interfaces ........................................... 48
7.1.3 Audit ....................................................................................................................... 50
7.1.4 Clustering ................................................................................................................ 50
7.1.5 Identiﬁcation and authentication ............................................................................. 51
7.1.6 Transaction Rollback ............................................................................................... 52
8 Abbreviations, Terminology, and References ...................................................... 53
8.1 Abbreviations ................................................................................................................... 53
Version: 2.0 Classiﬁcation: Public Page 4 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
8.2 Terminology ..................................................................................................................... 55
8.3 References ....................................................................................................................... 56
Version: 2.0 Classiﬁcation: Public Page 5 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
List of Tables
Table 1: Jakarta EE tier listing and JBoss EAP coverage ............................................................ 13
Table 2: Mapping of security objectives to threats and policies ................................................ 24
Table 3: Mapping of security objectives for the Operational Environment to assumptions, threats
and policies ......................................................................................................................... 24
Table 4: Suﬃciency of objectives countering threats ............................................................... 25
Table 5: Suﬃciency of objectives holding assumptions ............................................................ 25
Table 6: Suﬃciency of objectives enforcing Organizational Security Policies ............................ 26
Table 7: SFRs for the TOE ........................................................................................................ 28
Table 8: Mapping of security functional requirements to security objectives ............................ 39
Table 9: Security objectives for the TOE rationale .................................................................... 41
Table 10: TOE SFR dependency analysis .................................................................................. 43
Table 11: SARs ......................................................................................................................... 46
Table 12: Role-based access control pre-conﬁgured management roles ................................... 49
Version: 2.0 Classiﬁcation: Public Page 6 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
List of Figures
Figure 1: JBoss 8 Architecture .................................................................................................. 14
Version: 2.0 Classiﬁcation: Public Page 7 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
1 Introduction
1.1 Security Target Identiﬁcation
Title: JBoss Enterprise Application Platform 8 Version 8.1 Security Target
Version: 2.0
Status: Released
Date: 2026-01-30
Sponsor: Red Hat, Inc.
Developer: Red Hat, Inc.
Keywords: Security Target, Common Criteria, JBoss EAP, Jakarta EE, Application Server,
JBoss Enterprise Application Platform
1.2 TOE Identiﬁcation
The TOE is JBoss Enterprise Application Platform (EAP) 8 version 8.1.0.1.
1.3 TOE Type
The TOE type is Jakarta EE Application Server.
1.4 TOE Overview
This Security Target documents the security characteristics of the JBoss Enterprise Application Platform
(in the rest of this document the term “JBoss EAP” is used as a synonym for this TOE).
The TOE of JBoss EAP comprises the following components:
● JBoss EAP 8.1.0.1
The TOE does not include the hardware, ﬁrmware, operating system or Java virtual machine used to
run the software components.
The TOE is the JBoss Enterprise Application Platform which implements an application server. JBoss
EAP is based on the Java platform and therefore supports a large variety of operating systems. As
an application server, JBoss EAP allows client computers or devices to access applications. Access to
these applications is possible through diﬀerent network protocols, such as HTTP, RMI-IIOP, and others.
JBoss EAP handles the business logic of the application, including accessing and providing the user data
required by the application.
The TOE is deﬁned as a stand-alone JBoss EAP instance. If a cluster of JBoss EAP nodes is deﬁned, then
the entire cluster is deﬁned as one TOE.
1.4.1 TOE Type
JBoss Enterprise Application Platform (EAP) is a Java-based application server which provides many
advanced product features, including compliance with Jakarta EE 10, clustering, fail-over, and load
balancing.
Version: 2.0 Classiﬁcation: Public Page 8 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
1.4.2 Required Non-TOE Hardware and Software
The Operational Environment for the TOE allows the use of one of the following operating systems
together with one of the associated Java Development Kits (JDK):
● Red Hat Enterprise Linux 8 (x86_64)
❍ OpenJDK 17 and OpenJDK 21
❍ Oracle JDK 17 and Oracle JDK 21
❍ Adoptium JDK 17 and Adoptium JDK 21
● Red Hat Enterprise Linux 9 (x86_64)
❍ OpenJDK 17 and OpenJDK 21
❍ Oracle JDK 17 and Oracle JDK 21
❍ Adoptium JDK 17 and Adoptium JDK 21
● Red Hat Enterprise Linux 10 (x86_64)
❍ OpenJDK 17 and OpenJDK 21
❍ Oracle JDK 17 and Oracle JDK 21
❍ Adoptium JDK 17 and Adoptium JDK 21
● Microsoft Windows Server 2019 (x86_64)
❍ OpenJDK 17 and OpenJDK 21
❍ Oracle JDK 17 and Oracle JDK 21
❍ Adoptium JDK 17 and Adoptium JDK 21
● Microsoft Windows Server 2022 (x86_64)
❍ OpenJDK 17 and OpenJDK 21
❍ Oracle JDK 17 and Oracle JDK 21
❍ Adoptium JDK 17 and Adoptium JDK 21
For providing the cryptographic services supporting the TLS protocol on which the certiﬁcate-based
authentication relies on, the TOE uses as default the standard cryptographic service providers shipped
with the above mentioned Java Runtime Environments.
Native code in the operational environment, such as libAIO for Red Hat Enterprise Linux, cannot be
used in the evaluated conﬁguration.
As the TOE functionality only relies on the correct operation of the Java virtual machine, the TOE can
be executed on any operating system that is supported by the respective Java virtual machine. This
also means that any hardware supported by the aforementioned operating systems can be used to
execute the TOE.
The following relational databases are allowed to be used with the TOE (the listed databases are part
of the operational environment and therefore not covered with security claims in this Security Target):
● IBM DB2 Enterprise 12.1
● Oracle 19c RAC
● Oracle 23ai RAC
● MySQL 8.4
● MariaDB 11
● Microsoft SQL Server 2022
● PostgreSQL 17
Version: 2.0 Classiﬁcation: Public Page 9 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
● EnterpriseDB Advanced Server 17.5
● SAP ASE 16.1
The internal database (H2 DB) is not supported in the evaluated conﬁguration.
The following LDAP servers are allowed to be used with the TOE (they are part of the operational
environment and therefore not covered with security claims in this Security Target):
● Microsoft Active Directory 2019
● Microsoft Active Directory 2022
● Red Hat Directory Server 11.9
● Red Hat Directory Server 12.6
● Red Hat Directory Server 13.0
1.4.3 Intended Method of Use
The TOE is intended to operate in a networked environment with other instantiations of the TOE, as
well as other well-behaved client systems operating within the same management domain. All systems
need to be conﬁgured in accordance with a deﬁned common security policy. Communication links
between individual instances of the TOE can be protected against loss of conﬁdentiality and integrity
using separate physical networks or by cryptographic protection mechanisms supported by the TOE.
The data under the control of the TOE is stored in named objects, and the TOE can associate with each
named object a description of the access rights to that object.
Several TOE systems may be interlinked in a network. Individual networks may be joined by bridges
and/or routers. Each of the TOE instances implements its own security policy. The TOE does not include
any synchronization function for those policies between instances of the TOE. Please note that a fail-
over cluster conﬁguration of multiple instances of JBoss EAP is considered as one TOE. Therefore, the
synchronization operation between the cluster members is considered internal to the TOE. As a result,
a single user may have user accounts on each of those TOE instances with diﬀerent user IDs. One TOE
instance (either the standalone system or the cluster conﬁguration of the multiple JBoss EAP instances)
ensures its internal data consistency.
If other systems are connected to a network, they need to be conﬁgured and managed by the same
authority using an appropriate security policy that does not conﬂict with the security policy of the TOE.
1.4.4 Major Security Features
These are the primary security features of the TOE.
● Identiﬁcation and Authentication ensuring the proper identiﬁcation and authentication of
users to facilitate the various access control mechanisms.
● Access Control covering the objects of URLs, EJB methods, message queues and topics.
● Audit covering the access control decisions.
● Clustering ensuring the consistency of user and TSF data between cluster nodes.
● Transaction Rollback ensuring data consistency for user and TSF data.
● Role-based access control to administrative operations and resources.
These primary security features are supported by the appropriate use of domain separation and
reference mediation. This separation functionality is provided by the Java virtual machine if the Java
Security Manager is utilized. In addition, the underlying operating system supports this separation as
well ensuring that the security features are always invoked and cannot be bypassed, and that the TOE
can protect itself.
Version: 2.0 Classiﬁcation: Public Page 10 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
1.5 TOE Description
1.5.1 Introduction
The TOE representing an application server is implemented as a Jakarta EE framework, which allows
users to access Java applications over various network protocols. JBoss EAP executes Java applications
which are registered and are executed by the application server.
1.5.2 Application Server Deﬁnition
JBoss EAP is written entirely in Java and provides a Jakarta EE-compliant environment which is consistent
with the Jakarta EE 10 speciﬁcation ([JAKARTA_EE10]☝). Depending on the conﬁguration of the JBoss
EAP server, components required by the Jakarta EE speciﬁcation can be disabled. The applications
developed for and served by JBoss EAP are to be written in Java. Developers of the Java application
implement the business logic and are free to utilize the supporting functionality of Jakarta EE as
provided by JBoss EAP.
Figure 1 "JBoss 8 Architecture" documents the structure of JBoss EAP. The JBoss EAP architecture
provides the environment for the execution of diﬀerent containers which allow applications to utilize
services provided by these containers. The JBoss EAP framework uses a diﬀerent Java class loader for
each module. Applications executing within JBoss EAP containers, as well as JBoss EAP components, are
started within separate modules. Based on the JVM separation mechanism using diﬀerent class loaders,
the diﬀerent modules are isolated from each other. Using speciﬁcally conﬁgured dependencies, the
JBoss EAP framework allows the establishment of links between modules.
The conﬁguration of JBoss EAP allows selectively enabling or disabling every container, known as
extensions in JBoss EAP. The distribution of JBoss EAP provides a number of extensions that can be
utilized, but additional ones may be implemented by third parties. The evaluated conﬁguration deﬁnes
the extensions which are covered by the evaluation and therefore may be enabled in a CC-compliant
conﬁguration.
As part of the Jakarta EE framework implemented by JBoss EAP, applications can provide their logic to
remote clients through the following network protocols:
● HTTP protocol: Java servlets, EJBs, JMS queues provide their functionality based on URLs
requested by the client.
● Jakarta Enterprise Beans (EJB): Java classes can be made accessible to remote clients by
allowing these clients to access EJB classes and their methods using JBoss Remoting.
In addition to these protocols that can be used to access the business logic of an application,
various other protocols may be made accessible by the application server to support the application's
functionality – these protocols are provided by diﬀerent JBoss EAP containers and are unavailable if the
containers are disabled. Such additional protocols might be the following:
● A message queue protocol may be provided as a reliable and possibly asynchronous
communication channel. Such message queues may be used for the communication
between diﬀerent parts of distributed applications where diﬀerent parts of an application are
implemented in diﬀerent instances of the application server. Additionally, message queues
may be used for the application to client communication.
● A Java Naming and Directory Interface (JNDI) name resolution service may be provided by
the application server to allow diﬀerent parts of an application or the client to resolve EJB
classes and other resources.
In addition, JBoss EAP supports other protocols encapsulated in the aforementioned protocols, such
as HTML or SOAP transmitted over HTTP. However, the security mechanisms deﬁned by this ST are
enforced on the above mentioned outer layer protocols.
Version: 2.0 Classiﬁcation: Public Page 11 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
1.5.3 JBoss EAP Structure
JBoss EAP implements a system for innovative and scalable Java applications. It includes open source
technologies for deploying, and hosting enterprise Java applications and services.
JBoss EAP balances innovation with enterprise class stability by integrating the most popular clustered
Jakarta EE application server with next generation application frameworks. Built on open standards,
JBoss EAP integrates various containers implementing the Jakarta EE functionality, and other containers
providing mechanisms to applications which go beyond the Jakarta EE standard into a complete, simple
enterprise solution for Java applications.
The Jakarta EE speciﬁcation considers the following four layers, also called tiers. Applications utilizing
the Jakarta EE speciﬁcation may implement any combination of these tiers. In addition to listing the
tiers, the following table speciﬁes which tiers can be implemented and executed using the framework
of JBoss EAP.
Version: 2.0 Classiﬁcation: Public Page 12 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Table 1: Jakarta EE tier listing and JBoss EAP coverage
Jakarta EE Tier JBoss EAP Coverage
Client Tier
The client tier is the layer of the application
executed on the client system in order to display the
information provided by the application server. The
following artifacts can implement a client tier.
● An applet executed by the client’s Web browser.
● Javascript code executed by the client's Web
browser.
● A stand-alone Java application executed by the
client’s Java Virtual Machine.
● The JMS client.
The applet may be stored on the JBoss EAP server in
order for the client to automatically download it when
accessing a web page served by JBoss EAP.
However, neither the applet nor the application is
executed by the JBoss EAP application server, but they
are executed by the Java Virtual Machine of the client
system accessing the JBoss EAP information remotely.
Therefore, the client tier is considered to be not
covered by JBoss EAP.
Web Tier
The web tier is the presentation layer of the
application server. It gathers the business information
from the lower EJB tier and converts it to be presented
as web pages.
The web tier therefore does not implement
any business logic as it can be considered an
information converter from the application-internal
data representation to a user-viewable and user-
interpretable presentation.
Considering a web-shopping application, the web tier
implements the presenting layer with functionality
such as the web pages showing the sold products or
the display of the contents of the user’s shopping cart.
The web tier can be implemented using Java servlets
executing within the JBoss EAP framework supported
by diﬀerent frameworks provided by JBoss EAP, such
as RESTEasy.
The web tier is implemented by the customer-
developed application.
Business Tier
The business tier implements the business logic of the
entire application. Business logic is considered to be
the functionality implementing the information ﬂow
consistent with the purpose of the application.
Considering a web-shopping application, the
business tier implements business logic, such as the
management and maintenance of the sold products
and the shopping cart for each user.
The business tier can be implemented using
various types of EJBs executing within the JBoss
EAP framework. JBoss EAP also supports the
implementation of the business logic as Jakarta
Managed Beans (known in the past as POJOs or Plain-
Old Java Objects) which grant a greater degree of
freedom to the application developer compared to
EJBs.
The business tier is implemented by the customer-
developed application.
Enterprise Information System’s Tier
The enterprise information system’s tier provides the
logic to allow the business tier to access external data
stores. This tier therefore covers database access
mechanisms, such as a JDBC driver.
The TOE provides the interface to the enterprise
information system’s tier but does not implement the
databases hosting the business data. The TOE allows
the application EJBs or Jakarta Managed Beans to
access relational databases listed for JDBC.
The enterprise information system’s tier is not
implemented by the TOE.
Version: 2.0 Classiﬁcation: Public Page 13 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Fundamentally in the JBoss EAP architecture, the JBoss Module framework manages the set of pluggable
component services which are implemented as Jakarta Managed Beans. This allows assembling
diﬀerent conﬁgurations and provides the ﬂexibility to tailor the conﬁgurations to meet speciﬁc
requirements.
The administrator does not have to run a large, monolithic server all the time; as the components
that are not needed (which can also reduce the server startup time considerably) can be removed.
Also, additional services can be integrated into JBoss EAP by writing new MBeans. In addition, Jakarta
Managed Beans conﬁgured as services can be created for either extending the JBoss EAP functionality
or implementing business logic.
Figure 1 "JBoss 8 Architecture" shows the interoperation of the diﬀerent components of JBoss EAP. JBoss
EAP consists of a modular framework where the administrator can selectively enable components. JBoss
EAP oﬀers compliance with the Jakarta EE 10 speciﬁcation and oﬀers services beyond Jakarta EE. The
following description applies to the illustration:
● The hardware together with the operating system executes the Java virtual machine which
in turn executes the JBoss Modules framework. This framework provides the foundation on
which all JBoss EAP containers perform their tasks.
● Each container implements either a service as speciﬁed in Jakarta EE 10 or a service
providing additional functionality beyond Jakarta EE 10.
● Applications execute as part of containers (such as the JAX-RS Web Services container or the
EJB container) and may utilize services from other containers.
Figure 1: JBoss 8 Architecture
The TOE allows the interaction with users through the following services.
● HTTP web network protocol.
● RESTful (JAX-RS) and XML-Based (JAX-WS) Web Services.
● Jakarta Enterprise Beans (EJB).
● Jakarta Messaging Service (JMS).
● Java Naming and Directory Interface (JNDI).
Version: 2.0 Classiﬁcation: Public Page 14 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Applications utilize the services provided by the diﬀerent containers by accessing the API exported by
each container. These applications are loaded and executed by either the JSP/Servlet container, EJB
container or other containers. The technical separation of the untrusted applications and the TOE is
achieved using the Java Security Manager with an appropriate policy conﬁguration.
1.5.3.1 Java Security Manager
The evaluated conﬁguration of the TOE only allows the following mode of operation which has an
impact on how the TOE can protect itself against the behavior of applications or other untrusted code.
This mode utilizes the Java Security Manager provided by the Java Virtual Machine as part of the TOE
environment.
The Java Security Manager is utilized with a policy that completely protects the JBoss EAP execution from
any application or other untrusted code (such as the JDBC driver or preventing Java reﬂections) utilizing
the JBoss EAP framework. The Security Manager together with its policy prohibits any application from
accidentally or intentionally interfering with the operation of JBoss EAP.
It is not allowed to disable the Java Security Manager or to weaken the security policy delivered with
the TOE which ensures the protection of the TOE. Together with the TOE, the Security Manager policy
that protects the TOE from any application or other untrusted code is provided.
1.5.4 TOE boundaries
1.5.4.1 Physical
The TOE is the JBoss Enterprise Application Platform. Based on the above shown illustration, the TOE
consists of the JBoss Modules framework that instantiates the containers/services.
The TOE allows the use of all containers and supporting libraries distributed with JBoss EAP in
the evaluated conﬁguration (the containers shown in the picture above are present for a better
understanding of the TOE only and do not exhaustively list all components).
The TOE is supplied via the Red Hat Customer Portal [RHCP]☝, a secure web site. The security
administrator must access to the Red Hat Customer Portal using an account that has a subscription to
JBoss Enterprise Application Platform 8 Version 8.1
The TOE is available at the following URL: https://access.redhat.com/jbossnetwork/restricted/listS
oftware.html?product=appplatform&downloadType=distributions&version=8.1 and provided in two
ZIP packages: jboss-eap-8.1.0.zip and jboss-eap-8.1.0.1-maven-repository.zip. Integrity and
authenticity of these packages are ensured by running the following commands and verifying that the
SHA-256 hash value provided for each package in the download page matches the value obtained.
sha256sum jboss-eap-8.1.0.zip
sha256sum jboss-eap-8.1.0.1-maven-repository.zip
The obtained value must match the following SHA-256 hash values.
● jboss-eap-8.1.0.zip:
"c00ba9f5447a2e6280c0b55f3521052d1b53c18f08eea4acf366e572201f8a2b".
● jboss-eap-8.1.0.1-maven-repository.zip:
"8c1fdf0fc5b200b267bb08aee068fa135821a540d5ed1a77eef2621be331395a".
Section 3.4 "ZIP INSTALLATION" and subsection 3.4.1 "Download JBoss EAP" in the Common Criteria
Guide ([JBEAP-CCGUIDE]☝) shall be followed.
The Common Criteria Guide [JBEAP-CCGUIDE]☝ acts as the main guidance document including
the diﬀerent aspects of the evaluated conﬁguration of the TOE. The CC Guide can also be
downloaded from the Red Hat Customer Portal using the link provided in the bibliographic
Version: 2.0 Classiﬁcation: Public Page 15 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
references. In order to check the integrity and authenticity of the document, you can similarly
execute the command mentioned above. The obtained value must match the SHA-256 hash value
"94492a78087a6c4fb5a6d4a90745272559f8fc8e2f44dc797416f726b0688232".
Relevant guidance for the secure operation of the TOE are the following documents that are part of the
Red Hat JBoss Enterprise Application Platform 8.1 documentation.
● Common Criteria Guide [JBEAP-CCGUIDE]☝.
● Introduction to Red Hat JBoss Enterprise Application Platform [JBEAP-INTRO]☝.
● Getting Started with Red Hat JBoss Enterprise Application Platform [JBEAP-GS]☝.
● Getting Started with Management Console [JBEAP-MC]☝.
● Red Hat JBoss Enterprise Application Platform Installation Methods [JBEAP-IG]☝.
SHA-256 hash:
9a02b67bb154a28953b5d09ea94b2a6f938137d97ﬀ28dd7c648555dc7a40930
● Updating Red Hat JBoss Enterprise Application Platform[JBEAP-UPDT]☝.
● Conﬁguration Guide [JBEAP-CG]☝.
● Conﬁguring SSL/TLS in JBoss EAP [JBEAP-TLS]☝.
● Secure storage of credentials in JBoss EAP [JBEAP-CRED]☝.
● Securing applications and management interfaces using an identity store [JBEAP-IS]☝.
● Securing applications and management interfaces using multiple identity stores [JBEAP-
MIS]☝.
● Using single sign-on with JBoss EAP [JBEAP-SSO]☝.
● Getting started with developing applications for JBoss EAP deployment [JBEAP-GSD]☝.
● GA Public API JavaDocs [JBEAP-JD]☝.
In addition, the following Red Hat JBoss Enterprise Application Platform 7.4 documentation is also
applicable to the TOE.
● Development Guide [JBEAP-DG]☝.
● Developing Web Services Applications [JBEAP-DWSA]☝.
● Developing Jakarta Enterprise Beans Applications [JBEAP-DEJB]☝.
● Developing Hibernate Applications [JBEAP-DHA]☝.
● Managing Transactions on JBoss EAP [JBEAP-MT]☝.
● Conﬁguring Messaging [JBEAP-CM]☝.
● Security Architecture [JBEAP-SA]☝.
● How to Conﬁgure Server Security [JBEAP-CSS]☝.
● Login Module Reference [JBEAP-LMR]☝.
● Management CLI Guide [JBEAP-MCG]☝.
The integrity of the documents above can be also veriﬁed with the SHA-256 hash values provided in
Section 8.3.
1.5.4.2 Logical
The TOE provides the following security functionality:
● Security Audit: The TOE provides an audit mechanism that allows generating audit records
for security-relevant events concerning access control. The administrative user is able to
select the events which are to be audited.
Version: 2.0 Classiﬁcation: Public Page 16 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
● User Data Protection: The TOE enforces access control to subjects on data accessible to
HTTP and Web Services, EJBs, and message queue and topics for JMS. The TOE also enforces
role-based access for security management. In addition, user data is protected by allowing
transaction rollback in case an operation that is part of a transaction fails.
● Identiﬁcation and Authentication: The TOE implements identiﬁcation and authentication
based on username and password, and X.509 certiﬁcates. Notice that this functionality does
not include X.509 certiﬁcate validation as part of the TLS protocol, which is covered by the
underlying JDK (see A.TLS).
● Security Management: The TOE implements security management interfaces for the
conﬁguration of access control policies.
● Protection of the TSF: The TOE ensures consistency of the TSF data in separate TOE
instances by implementing cluster communication, which synchronizes the runtime state of
the diﬀerent cluster nodes.
1.5.4.2.1 Evaluated conﬁguration
The evaluated conﬁgurations are deﬁned as follows.
● The web management interface provides a web-based access to the management API for
administering the TOE. That interface provides access to the conﬁguration aspects that can
be set via the XML-based central conﬁguration ﬁle for JBoss EAP. The conﬁguration of the
TOE restricts access to administrative users.
● The console management interface provides a command line interface access to the
management API for administering the TOE. That interface provides access to the
conﬁguration aspects that can be set via the XML-based central conﬁguration ﬁle for JBoss
EAP. By default conﬁguration of the TOE restricts access to administrative users. The
management interface oﬀers a role-based access control mechanism to access various
management aspects. This way, roles can be deﬁned and mapped to users which limit users
to certain administrative operations.
● JBoss remoting allows users to access the JBoss Mbean server component to perform
administrative tasks. It must be protected against all users who are not trusted
administrators. By default conﬁguration of the TOE restricts access to administrative users.
● The JDBC drivers connecting to any of the database servers must be separated from the TOE
using the provided Java Security Manager policy. The Security Manager policy is distributed
with the TOE.
● The Security Manager must not allow applications to load native code and restrict the Java
reﬂection API.
1.5.4.3 Security Policy Model
The security policy for JBoss EAP is deﬁned by the security functional requirements in chapter 6. The
following is a list of the subjects and objects participating in the policy.
Subjects
● Users represented by a Principal or Subject object assigned to a management role
represented by the Group object.
Objects
● Data accessible at an URL.
● EJBs and associated methods.
● Message queue and topic.
● Target conﬁguration resource and target conﬁguration attribute for a resource.
Version: 2.0 Classiﬁcation: Public Page 17 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
TSF data
● Deployment descriptors.
● Security annotations as part of the Java source code.
● User accounts, including the security attributes deﬁned by FIA_ATD.1.
● Audit records.
● JBoss EAP conﬁguration data.
User data
● Applications deployed with the TOE and all data controlled by them.
Version: 2.0 Classiﬁcation: Public Page 18 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
2 CC Conformance Claim
This Security Target is CC Part 2 extended and CC Part 3 conformant, with a claimed Evaluation
Assurance Level of EAL2, augmented by ALC_FLR.3.
This Security Target does not claim conformance to any Protection Proﬁle.
Common Criteria [CC] version 3.1 revision 5 is the basis for this conformance claim.
Version: 2.0 Classiﬁcation: Public Page 19 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
3 Security Problem Deﬁnition
3.1 Threat Environment
This section describes the threat model for the TOE and identiﬁes the individual threats that are
assumed to exist in the TOE environment.
The assets to be protected by the TOE comprise of the information stored, processed or transmitted
by the TOE. The term “information” is used here to refer to all data held within the application server,
including data in transit between instances of the application server.
The TOE counters the general threat of unauthorized access to information, where “access” includes
disclosure, modiﬁcation and destruction.
The threat agents having an interest in manipulating the data model can be categorized as either:
● Unauthorized users of the TOE, i.e., individuals who have not been granted the right to
access the system.
● Authorized users of the TOE, i.e., individuals who have been granted the right to access the
system.
The threat agents are assumed to originate from a well managed user community in a non-hostile
working environment, and hence the product protects against threats of security vulnerabilities that
might be exploited in the intended environment for the TOE with medium level of expertise and eﬀort.
The TOE protects against straightforward or intentional breach of TOE security by attackers possessing
an enhanced-basic attack potential.
3.1.1 Threats countered by the TOE
T.UAUSER
An attacker (possibly, but not necessarily, an unauthorized user of the TOE) may impersonate
an authorized user of the TOE. This includes the threat of an authorized user that tries to
impersonate as another authorized user without knowing the authentication information.
T.ACCESS.USER
An authorized user may gain access to resources or perform operations for which no access
rights have been granted.
T.ACCESS.MGT
An administrator may gain access to administrative resources or perform administrative
operations for which no access rights have been granted.
T.DIFFER
An authorized user may cause user data or TSF data that is stored in multiple places to
become inconsistent and cause either user data loss or circumvention of TSF.
Version: 2.0 Classiﬁcation: Public Page 20 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
3.2 Assumptions
3.2.1 Environment of use of the TOE
3.2.1.1 Physical
A.PROTECT
The hardware and software executing the TOE as well as the TOE software critical to security
policy enforcement will be protected from unauthorized modiﬁcation including unauthorized
modiﬁcations by potentially hostile outsiders.
3.2.1.2 Personnel
A.ADMIN
It is assumed that there are one or more competent individuals who are assigned to manage
the TOE and the TOE environment and the security of the information it contains. The system
administrative personnel are not careless, willfully negligent, or hostile, and will follow and
abide by the instructions provided by the administrator documentation.
A.DEVEL
The developer of user applications executed by the TOE, including web server applications
and enterprise beans, is trustworthy and will comply with all instructions set forth by the user
guidance and evaluated conﬁguration guidance of the TOE.
3.2.1.3 Connectivity
A.SYSTEM
The operating system and the Java virtual machine operate according to their speciﬁcation.
These external systems are conﬁgured in accordance with the installation guidance and the
evaluated conﬁguration guidance of the TOE.
A.CLUSTER
The TOE is operated on a system that provides three separate network interfaces following 3-
tier conﬁguration of the TOE where the underlying operating system separates the network
traﬃc to these interfaces:
● The network ports of 8080 and 8443 are bound to the public-facing network interface
accessible by users interacting with the TOE.
● If the TOE is conﬁgured as a cluster, all cluster related ports are bound to a cluster
network interface.
● The remaining network ports are bound to an internal network interface where the
network is at most only accessible by administrators.
A.PEER
Any other system with which the TOE communicates is assumed to be under the same
management control and operate under the same security policy constraints as the TOE itself.
A.TLS
The underlying JDK performs a correct and complete certiﬁcate validation of any oﬀered X.509
client certiﬁcate.
Version: 2.0 Classiﬁcation: Public Page 21 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
3.3 Organizational Security Policies
P.ACCOUNTABILITY
The users of the system shall be held accountable for their actions within the system.
Version: 2.0 Classiﬁcation: Public Page 22 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
4 Security Objectives
4.1 Objectives for the TOE
O.AUTHORIZATION
The TOE must ensure that only identiﬁed and authorized users gain access to the TOE and its
resources.
O.ACCESS
The TSF must control access to resources based on identity of users. The TSF must allow
authorized users to specify which resources may be accessed by which users.
O.ROLE
The TSF must control access to administrative resources as well as administrative operations
based on the role a user is assigned to. The TSF must allow authorized users to specify which
resources may be accessed by which users.
O.AUDITING
The TSF must record security relevant actions of users of the TOE. The information recorded
with security relevant events must be in suﬃcient detail to help an administrator of the TOE
detect attempted security violations or potential misconﬁguration of the TOE security features
that would leave the IT assets open to compromise.
O.CONSISTENCY
The TSF must ensure the consistency of user data as well as TSF data while it is being
processed. Consistency needs to be ensured when data is processed that may be located in
multiple places.
4.2 Objectives for the Operational Environment
OE.ADMIN
Those responsible for the administration of the TOE are competent and trustworthy
individuals, capable of managing the TOE and the security of the information it contains.
OE.SYSTEM
Those responsible for the TOE must ensure that the operating system and the Java virtual
machine are installed and conﬁgured in accordance with the guidance of the TOE and that
these mechanisms operate as speciﬁed. This also covers that only the Java virtual machines
enumerated in this ST are used as underlying platform to ensure that proper date and time
information is available to the audit facility.
OE.INSTALL
Those responsible for the TOE must establish and implement procedures to ensure that
the software components that comprise the TOE are distributed, installed, conﬁgured and
administered in a secure manner.
OE.PHYSICAL
Those responsible for the TOE must ensure that those parts of the TOE critical to security
policy as well as the underlying hardware and software are protected from physical attack
which might compromise IT security objectives.
Version: 2.0 Classiﬁcation: Public Page 23 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
OE.RECOVER
Those responsible for the TOE must ensure that procedures and/or mechanisms are provided
to assure that, after system failure or other discontinuity, recovery without a protection (i.e.,
security) compromise is obtained.
OE.DEVEL
Those responsible for the TOE shall ensure that the developers of the applications executed
by the TOE are trustworthy and implement the applications in accordance with the guidance
provided with the TOE.
4.3 Security Objectives Rationale
4.3.1 Security objectives coverage
The following table provides a mapping of TOE objectives to threats and policies, showing that each
objective counters or enforces at least one threat or policy, respectively.
Table 2: Mapping of security objectives to threats and policies
Objective Threats / OSPs
O.AUTHORIZATION T.UAUSER
O.ACCESS T.ACCESS.USER
O.ROLE T.ACCESS.MGT
O.AUDITING P.ACCOUNTABILITY
O.CONSISTENCY T.DIFFER
The following table provides a mapping of the objectives for the Operational Environment to
assumptions, threats and policies, showing that each objective holds, counters or enforces at least one
assumption, threat or policy, respectively.
Table 3: Mapping of security objectives for the Operational Environment to assumptions, threats and policies
Objective Assumptions / Threats / OSPs
OE.ADMIN A.ADMIN
OE.SYSTEM A.SYSTEM
P.ACCOUNTABILITY
OE.INSTALL A.ADMIN
A.CLUSTER
A.PEER
A.TLS
OE.PHYSICAL A.PROTECT
OE.RECOVER A.ADMIN
OE.DEVEL A.DEVEL
Version: 2.0 Classiﬁcation: Public Page 24 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
4.3.2 Security objectives suﬃciency
The following rationale provides justiﬁcation that the security objectives are suitable to counter each
individual threat and that each security objective tracing back to a threat, when achieved, actually
contributes to the removal, diminishing or mitigation of that threat.
Table 4: Suﬃciency of objectives countering threats
Threat Rationale for Security Objectives
T.UAUSER The threat of impersonation of an authorized user by an attacker
is suﬃciently diminished by O.AUTHORIZATION requiring proper
authorization of users gaining access to the TOE. The access control
attributes are protected by the environment to be accessible to the
administrator only.
T.ACCESS.USER The threat of an authorized user of the TOE accessing information
resources without the permission from the user responsible for the
resource is removed by O.ACCESS requiring access control for resources
and the ability for authorized users to specify the access to their resources.
This ensures that a user can access a resource only if the requested type
of access has been granted by the user responsible for the management
of access rights to the resource.
T.ACCESS.MGT The threat of an administrator deﬁned by the diﬀerent administrative
roles listed in the table titled Pre-Conﬁgured Management Roles, accessing
information resources without authorization from the administrator role
responsible for the TOE is removed by O.ROLE requiring a role-based
access control for administrative resources and administrative operations.
This ensures that an administrator can access such resources and
operations only if the requested type of access has been granted by the
master administrator responsible for the management of the assignment
of roles to users and capabilities to roles.
T.DIFFER The threat of user data and TSF data being inconsistent among
diﬀerent parts of the TOE is diminished by the functionality provided by
O.CONSISTENCY requiring that a mechanism is enforced that ensures the
consistency of the data.
The following rationale provides justiﬁcation that the security objectives for the environment are
suitable to cover each individual assumption, that each security objective for the environment that
traces back to an assumption about the environment of use of the TOE, when achieved, actually
contributes to the environment achieving consistency with the assumption, and that if all security
objectives for the environment that trace back to an assumption are achieved, the intended usage is
supported.
Table 5: Suﬃciency of objectives holding assumptions
Assumption Rationale for Security Objectives
A.PROTECT The assumption on physical protection of all hard- and software as
well as the network and peripheral cabling is covered by the objectives
OE.PHYSICAL requiring physical protection.
A.ADMIN The assumption on competent administrators is covered by OE.ADMIN
requiring competent and trustworthy administrators and OE.INSTALL
requiring procedures for secure distribution, installation and conﬁguration
Version: 2.0 Classiﬁcation: Public Page 25 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Assumption Rationale for Security Objectives
of systems as well as OE.RECOVER requiring the administrator to perform
all the required actions to bring the TOE into a secure state after a system
failure or discontinuity.
A.DEVEL The assumption on developers of applications executed by the TOE to be
trustworthy and to comply with the instructions set forth in the guidance
is covered by OE.DEVEL requiring the administrator to ensure that these
developers are indeed trustworthy.
A.SYSTEM The assumption that the environment the TOE relies on to enforce its
functionality (the OS and the Java virtual machine) is conﬁgured according
to the guidance provided by the TOE is covered by OE.SYSTEM requiring
the administrator to comply with that guidance.
A.CLUSTER The assumption that the TOE is conﬁgured with the 3-tier conﬁguration is
covered by OE.INSTALL requiring the administrator to install the TOE in a
secure manner.
A.PEER The assumption on the same management control and security policy
constraints for systems with which the TOE communicates is covered by
OE.INSTALL requiring procedures for secure distribution, installation and
conﬁguration of the networked system.
A.TLS The assumption of a correct and complete certiﬁcate validation is covered
by OE.INSTALL requiring procedures for the installation and conﬁguration
of the TOE on a list of allowed JDKs. These JDKs are assumed to correctly
implement the certiﬁcate validation.
The following rationale provides justiﬁcation that the security objectives are suitable to cover each
individual organizational security policy (OSP), that each security objective that traces back to an OSP,
when achieved, actually contributes to the implementation of the OSP, and that if all security objectives
that trace back to an OSP are achieved, the OSP is implemented.
Table 6: Suﬃciency of objectives enforcing Organizational Security Policies
OSP Rationale for Security Objectives
P.ACCOUNTABILITY The policy to provide a means to hold users accountable for their
activities is implemented by O.AUDITING providing the TOE with such
functionality. To generate appropriate audit entries, OE.SYSTEM ensures
that the underlying system provides the time stamp for any action to be
audited.
Version: 2.0 Classiﬁcation: Public Page 26 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
5 Extended Components Deﬁnition
The Security Target deﬁnes the extended component FDP_ROL_EXT.2 as part of the FDP_ROL family
in CC Part 2 for usage within this ST.
5.1 Class FDP: User data protection
5.1.1 Rollback (FDP_ROL)
Component levelling
The SFR is not hierarchical to any other SFR out of the family of FDP_ROL.
Management: FDP_ROL_EXT.2
The following actions could be considered for the management functions in FMT:
a) The boundary limit to which rollback may be performed could be conﬁgurable item within the
TOE.
Audit: FDP_ROL_EXT.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the
PP/ST:
a) Minimal: Please see the audit information on the FDP_ROL family in CC Part 2.
b) Basic: Please see the audit information on the FDP_ROL family in CC Part 2.
c) Detailed: Please see the audit information on the FDP_ROL family in CC Part 2.
5.1.1.1 FDP_ROL_EXT.2 Automated rollback
Component
relationships
Hierarchical to: No other components.
Dependencies: No dependencies.
FDP_ROL_EXT.2.1 The TSF shall perform an automated rollback of all the operations [assignment:
list of sub-operations belonging to one operation] when [assignment:
list of causes for a rollback of all operations] .
Rationale
The SFR of FDP_ROL_EXT.2 is intended to specify an automated rollback of operations by the TOE.
Automated rollback addresses the need to roll back or undo all operations within the deﬁned bounds.
Version: 2.0 Classiﬁcation: Public Page 27 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
6 Security Requirements
6.1 TOE Security Functional Requirements
The table below summarizes the SFRs for the TOE and the operations performed on the components
according to CC part 1. Operations in the SFRs use the following convention:
● Iterations (Iter.) are identiﬁed by appending a suﬃx to the original SFR.
● Reﬁnements (Ref.) added to the text are shown in italic text, deletions are shown as
strikethrough text.
● Assignments (Ass.) are shown in bold text.
● Selections (Sel.) are shown in bold text.
Table 7: SFRs for the TOE
Operations
Security
Functional
Group
Security Functional
Requirement
Base
Security
Functional
Component
Source
Iter. Ref. Ass. Sel.
FAU_GEN.1 Audit data generation CC Part 2 No No Yes Yes
FAU_GEN.2 User identity association CC Part 2 No No No No
FDP_ACC.1(HTTP) HTTP Access
Control Policy
FDP_ACC.1 CC Part 2 Yes No Yes No
FDP_ACC.1(EJB) EJB Access Control
Policy
FDP_ACC.1 CC Part 2 Yes No Yes No
FDP_ACC.1(JMS) JMS Access Control
Policy
FDP_ACC.1 CC Part 2 Yes No Yes No
FDP_ACF.1(HTTP) HTTP Access
Control Functions
FDP_ACF.1 CC Part 2 Yes No Yes No
FDP_ACF.1(EJB) EJB Access Control
Functions
FDP_ACF.1 CC Part 2 Yes No Yes No
FDP_ACF.1(JMS) JMS Access Control
Functions
FDP_ACF.1 CC Part 2 Yes No Yes No
FDP_ROL_EXT.2 Automated rollback ECD No No Yes No
FIA_ATD.1 User attribute deﬁnition CC Part 2 No No Yes No
FIA_UAU.1 Timing of authentication CC Part 2 No Yes Yes No
FIA_UID.1 Timing of identiﬁcation CC Part 2 No Yes Yes No
FIA_USB.1 User-subject binding CC Part 2 No No Yes No
FMT_MSA.1(EJB) Management of
object security attributes
FMT_MSA.1 CC Part 2 Yes No Yes Yes
FMT_MSA.1(JMS) Management of
object security attributes
FMT_MSA.1 CC Part 2 Yes No Yes Yes
Jakarta EE
Security
Mechanisms
FMT_MSA.3(WEB) Static attribute
initialisation
FMT_MSA.3 CC Part 2 Yes Yes Yes Yes
Version: 2.0 Classiﬁcation: Public Page 28 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Operations
Security
Functional
Group
Security Functional
Requirement
Base
Security
Functional
Component
Source
Iter. Ref. Ass. Sel.
FMT_MSA.3(EJB) Static attribute
initialisation
FMT_MSA.3 CC Part 2 Yes Yes Yes Yes
FMT_MSA.3(JMS) Static attribute
initialization
FMT_MSA.3 CC Part 2 Yes Yes Yes Yes
FMT_MTD.1(ACC) Management of
TSF data
FMT_MTD.1 CC Part 2 Yes No Yes Yes
FMT_MTD.1(JMS) Management of
TSF data
FMT_MTD.1 CC Part 2 Yes No Yes Yes
FMT_MTD.1(AUTH) Management of
TSF data
FMT_MTD.1 CC Part 2 Yes No Yes Yes
FPT_TRC.1 Internal TSF consistency CC Part 2 No No Yes No
FDP_ACC.1(RBAC) Role-Based
Access Control Policy
FDP_ACC.1 CC Part 2 Yes No Yes No
FDP_ACF.1(RBAC) Role-Based
Access Control Functions
FDP_ACF.1 CC Part 2 Yes No Yes No
FMT_MSA.1(RBAC) Management of
object security attributes
FMT_MSA.1 CC Part 2 Yes No Yes Yes
FMT_MSA.3(RBAC) Static attribute
initialization
FMT_MSA.3 CC Part 2 Yes No Yes Yes
FMT_SMF.1 Speciﬁcation of
management functions
CC Part 2 No No Yes No
JBoss EAP
Management
security
FMT_SMR.2 Security roles CC Part 2 No No Yes No
6.1.1 Jakarta EE Security Mechanisms
6.1.1.1 FAU_GEN.1 Audit data generation
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable
events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the not speciﬁed level of audit; and
c) Each access request for each access control policy;
FAU_GEN.1.2 The TSF shall record within each audit record at least the following information:
a) Date and time of the event, type of event, subject identity (if applicable),
and the outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event deﬁnitions of the
functional components included in the PP/ST, no additional information.
Application Note: The subject identity is deﬁned by container and thread ID.
Version: 2.0 Classiﬁcation: Public Page 29 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
6.1.1.2 FAU_GEN.2 User identity association
FAU_GEN.2.1 For audit events resulting from actions of identiﬁed users, the TSF shall be able
to associate each auditable event with the identity of the user that caused the
event.
6.1.1.3 FDP_ACC.1(HTTP) HTTP Access Control Policy
FDP_ACC.1.1(HTTP) The TSF shall enforce the HTTP Access Control policy on
Subject: a user represented by a Principal or Subject object assigned
to a user role represented by the Group object;
Object: data accessible at URL;
Operations: all HTTP standard and user-deﬁned methods
Application Note: Access control is managed with appropriate settings in the deployment
descriptor of web.xml.
Application Note: The access control functionality implemented by the web subsystem as
speciﬁed in this SFR also covers access to web services application.
6.1.1.4 FDP_ACC.1(EJB) EJB Access Control Policy
FDP_ACC.1.1(EJB) The TSF shall enforce the EJB Access Control policy on
Subject: a user represented by a Principal or Subject object assigned
to a user role represented by the Group object;
Objects: EJB and associated method;
Operations: calling the method of the EJB.
Application Note: Access control is managed with appropriate settings in the deployment
descriptor ejb-jar.xml and the “@RolesAllowed”, “@DenyAll”, “@PermitAll” Java Annotations in the
Java source code of the aﬀected EJB .
6.1.1.5 FDP_ACC.1(JMS) JMS Access Control Policy
FDP_ACC.1.1(JMS) The TSF shall enforce the JMS Access Control policy on
Subject: a user represented by a Principal or Subject object assigned
to a user role represented by the Group object;
Objects: message queue, topic;
Operations: create-durable-queue, delete-durable-queue, create-non-
durable-queue, delete-non-durable-queue, send, consume, manage
Application Note: Access control is managed with appropriate settings in the TOE conﬁguration.
Application Note: Message queues (one sender, one receiver) and topics (one sender, multiple
receivers) are communication facilities allowing diﬀerent subjects to exchange information.
Version: 2.0 Classiﬁcation: Public Page 30 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
6.1.1.6 FDP_ACF.1(HTTP) HTTP Access Control Functions
FDP_ACF.1.1(HTTP) The TSF shall enforce the HTTP Access Control Policy to objects based on
the following:
a) Subject attributes: User roles;
b) Object attributes: URL, user roles.
FDP_ACF.1.2(HTTP) The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed:
Access to the URL with the requested HTTP method is permitted if:
a) Deployment descriptor / conﬁguration ﬁle: the requesting user
is associated with a user role speciﬁed for the URL and HTTP
method in the “security-constraint” element deﬁned in the
deployment descriptor web.xml;
b) Deployment descriptor / conﬁguration ﬁle: the transport layer
security used when accessing the URL must cover at least that
security mechanism deﬁned by the “user-data-constraint”
element deﬁned in the deployment descriptor web.xml for the
accessed URL, requiring either no protection, integrity protection
or conﬁdentiality protection.
FDP_ACF.1.3(HTTP) The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: None.
FDP_ACF.1.4(HTTP) The TSF shall explicitly deny access of subjects to objects based on the
following additional rules: providing an empty auth-constraint element.
Application Note: Application developers have the possibility to deﬁne additional access control
rules in the deployment descriptors applicable to their applications. The TOE provides mechanisms
like ACLs which can be used to provide additional access restrictions. However, these additional
access control mechanisms can only add additional restrictions without violating the restrictions
deﬁned in this SFR. Therefore, these additional access control mechanisms are allowed to be
used although not attributed with security claims in this ST and therefore outside the scope of the
evaluation.
6.1.1.7 FDP_ACF.1(EJB) EJB Access Control Functions
FDP_ACF.1.1(EJB) The TSF shall enforce the EJB Access Control Policy to objects based on the
following:
a) Subject attributes: User roles;
b) Object attributes: EJB name and associated method name, user
roles.
FDP_ACF.1.2(EJB) The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed:
Version: 2.0 Classiﬁcation: Public Page 31 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Access to the EJB method is permitted if the requesting user is
associated with a user role speciﬁed for the EJB method in the
“method-permission” element deﬁned in the deployment descriptor
ejb-jar.xml.
FDP_ACF.1.3(EJB) The TSF shall explicitly authorise access of subjects to objects based
on the following additional rules: permission rules marked with the
“unchecked” element instead of the “role-name” element deﬁne that
any authenticated user can access the EJB method.
FDP_ACF.1.4(EJB) The TSF shall explicitly deny access of subjects to objects based on the
following additional rules: methods marked with the “exclude-list”
element are always denied access to.
Application Note: Application developers have the possibility to deﬁne additional access control
rules in the deployment descriptors applicable to their applications. The TOE provides mechanisms
like ACLs which can be used to provide additional access restrictions. However, these additional
access control mechanisms can only add additional restrictions without violating the restrictions
deﬁned in this SFR. Therefore, these additional access control mechanisms are allowed to be
used although not attributed with security claims in this ST and therefore outside the scope of the
evaluation.
6.1.1.8 FDP_ACF.1(JMS) JMS Access Control Functions
FDP_ACF.1.1(JMS) The TSF shall enforce the JMS Access Control Policy to objects based on the
following:
a) Subject attributes: User roles;
b) Object attributes: message queue name, topic name, user roles.
FDP_ACF.1.2(JMS) The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed: Access to the message
queue or topic is permitted if the requesting user is associated with a
user role speciﬁed for the respective communication facility based on
the following rules:
a) createDurableQueue. This permission allows the user to create a
durable queue under matching addresses.
b) deleteDurableQueue. This permission allows the user to delete a
durable queue under matching addresses.
c) createNonDurableQueue. This permission allows the user to
create a non-durable queue under matching addresses.
d) deleteNonDurableQueue. This permission allows the user to
delete a non-durable queue under matching addresses.
e) send. This permission allows the user to send a message to
matching addresses.
f) consume. This permission allows the user to consume a message
from a queue bound to matching addresses.
Version: 2.0 Classiﬁcation: Public Page 32 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
g) manage. This permission allows the user to invoke management
operations by sending management messages to the
management address.
FDP_ACF.1.3(JMS) The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: none.
FDP_ACF.1.4(JMS) The TSF shall explicitly deny access of subjects to objects based on the
following additional rules: none.
6.1.1.9 FDP_ROL_EXT.2 Automated rollback
FDP_ROL_EXT.2.1 The TSF shall perform an automated rollback of all the operations deﬁned to
form one transaction when at least one operation part of a transaction
fails.
6.1.1.10 FIA_ATD.1 User attribute deﬁnition
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to
individual users:
a) Subject identity;
b) User Role;
c) Management Role;
d) Password, if the services of HTTP (basic, digest and form-based
authentication), EJB, and JMS are available to the user;
e) X.509 Certiﬁcate if the certiﬁcate-based authentications service
of HTTP is available to the user.
Application Note: The TOE user databases are conﬁgured in the TOE conﬁguration. Various user
databases can be conﬁgured and mapped to the diﬀerent services oﬀered by the TOE. In addition,
Java annotations can be used to deﬁne users.
6.1.1.11 FIA_UAU.1 Timing of authentication
FIA_UAU.1.1 The TSF shall allow the following actions on behalf of the user to be
performed before the user is authenticated except for the certiﬁcate based
authentication implemented with JBoss Remoting:
1. All actions allowed by the access control mechanisms for the identity
assigned to an unauthenticated principal deﬁned by the container
implementing the respective action.
2. All actions allowed by the access control mechanism to unsecured EJBs
or EJB methods that are associated with the unchecked permission
constraint for the identity assigned to unauthenticated users with the
“unauthenticatedIdentity” element in the login module conﬁguration.
3. All URLs (i) without a “security-constraint” element deﬁned in the
web.xml deployment descriptor, or (ii) without the “@RolesAllowed”
and without the “@DenyAll” Java Annotations deﬁned for EJB servlets,
Version: 2.0 Classiﬁcation: Public Page 33 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
or (iii) without the @ServletSecurity(@HttpConstraint(rolesAllowed))
@ServletSecurity(@HttpMethodConstraint(rolesAllowed)) Java Annotation
are accessible to unauthenticated users.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before
allowing any other TSF-mediated actions on behalf of that user.
Application Note: For the certiﬁcate based authentication implemented with JBoss Remoting,
A.TLS applies instead of FIA_UAU.1.
6.1.1.12 FIA_UID.1 Timing of identiﬁcation
FIA_UID.1.1 The TSF shall allow the following actions on behalf of the user to be
performed before the user is identiﬁed:
1. All actions allowed by the access control mechanisms for the identity
assigned to an unauthenticated principal deﬁned by the container
implementing the respective action.
2. All actions allowed by the access control mechanism to unsecured EJBs
or EJB methods that are associated with the unchecked permission
constraint for the identity assigned to unauthenticated users with the
“unauthenticatedIdentity” element in the login module conﬁguration.
3. All URLs (i) without a “security-constraint” element deﬁned in the
web.xml deployment descriptor, or (ii) without the “@RolesAllowed”
and without the “@DenyAll” Java Annotations, or (iii) without
the @ServletSecurity(@HttpConstraint(rolesAllowed)) or
@ServletSecurity(@HttpMethodConstraint(rolesAllowed)) Java Annotation
deﬁned for EJB servlets are accessible to unauthenticated users.
FIA_UID.1.2 The TSF shall require each user to be successfully identiﬁed before allowing
any other TSF-mediated actions on behalf of that user.
6.1.1.13 FIA_USB.1 User-subject binding
FIA_USB.1.1 The TSF shall associate the following user security attributes with subjects
acting on the behalf of that user:
a) Subject identity associated with auditable events;
b) User role the user is operating with as used by the diﬀerent
access control mechanisms deﬁned in FDP_ACC.1(HTTP),
FDP_ACC.1(EJB), FDP_ACC.1(JMS);
c) Administrative role the user is operating with as used by the
management interfaces deﬁned by FDP_ACC.1(RBAC), FMT_SMR.2.
FIA_USB.1.2 The TSF shall enforce the following rules on the initial association of user
security attributes with subjects acting on the behalf of users:
a) Upon successful identiﬁcation and authentication, the user
identity shall be that speciﬁed in the user entry for the user that
has authenticated.
Version: 2.0 Classiﬁcation: Public Page 34 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
b) The user role associated with a subject shall be one of the
authorized roles assigned to the user.
c) The management role associated with a subject shall be all of the
authorized roles assigned to the user.
FIA_USB.1.3 The TSF shall enforce the following rules governing changes to the user
security attributes associated with subjects acting on the behalf of users:
a) run-as: The security role deﬁned with the run-as element in a
deployment descriptor or @RunAs annotation is used for the
execution of methods invoked by the component marked by run-
as.
b) run-as-principal: The identity (principal) deﬁned with the
run-as-principal element in a deployment descriptor or the
@RunAsPrincipal annotation is used for the execution of methods
invoked by the component marked by run-as-principal.
6.1.1.14 FMT_MSA.1(EJB) Management of object security attributes
FMT_MSA.1.1(EJB) The TSF shall enforce the EJB Access Control Policy to restrict the ability
to modify the security attributes of the default value of the SFP to
authorized administrators assigned to the maintainer role, deployer
role, administrator role or superuser role.
6.1.1.15 FMT_MSA.1(JMS) Management of object security attributes
FMT_MSA.1.1(JMS) The TSF shall enforce the JMS Access Control Policy to restrict the ability
to modify the security attributes of the default value of the SFP to
authorized administrators assigned to the maintainer role, deployer
role, administrator role or superuser role.
6.1.1.16 FMT_MSA.3(WEB) Static attribute initialisation
FMT_MSA.3.1(WEB) The TSF shall enforce the HTTP Access Control Policy to provide
permissive default values for security attributes that are used to enforce the
SFP.
FMT_MSA.3.2(WEB) The TSF shall allow the nobody to specify alternative initial values to override
the default values when an object or information is created.
Application Note: The default values are hard-coded and cannot be changed.
6.1.1.17 FMT_MSA.3(EJB) Static attribute initialisation
FMT_MSA.3.1(EJB) The TSF shall enforce the EJB Access Control Policy to provide restrictive
default values for security attributes that are used to enforce the SFP.
Version: 2.0 Classiﬁcation: Public Page 35 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
FMT_MSA.3.2(EJB) The TSF shall allow the authorized administrators assigned to the
maintainer role, deployer role, administrator role or superuser role to
specify alternative initial values to override the default values when an object
or information is created.
Application Note: The default value can be changed with the default-missing-method-permission-
deny-access conﬁguration value.
6.1.1.18 FMT_MSA.3(JMS) Static attribute initialization
FMT_MSA.3.1(JMS) The TSF shall enforce the JMS Access Control Policy to provide restrictive
default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2(JMS) The TSF shall allow the authorized administrators assigned to the
maintainer role, deployer role, administrator role or superuser role to
specify alternative initial values to override the default values when an object
or information is created.
Application Note: The default behavior for message queue or topic destinations is deﬁned with the
JBoss system conﬁguration.
Application Note: This SFR speciﬁes the management of the default value. For protecting the
default value, the TOE relies on the environment to protect the deployment descriptor ﬁle holding
the default value. As only authorized administrators are able to access the system hosting the TOE as
assumed with A.PROTECT, the protection of the deployment descriptor is ensured.
6.1.1.19 FMT_MTD.1(ACC) Management of TSF data
FMT_MTD.1.1(ACC) The TSF shall restrict the ability to modify the access control settings for
the HTTP Access Control Policy, EJB Access Control Policy to the user
owning the application the access control restrictions apply to.
Application Note: The access control policies are deﬁned in the deployment descriptor or other
locations for each application as referenced in the application notes for each FDP_ACC.1 iteration.
6.1.1.20 FMT_MTD.1(JMS) Management of TSF data
FMT_MTD.1.1(JMS) The TSF shall restrict the ability to modify the access control settings for
the JMS Access Control Policy, to authorized administrators assigned
to the maintainer role, deployer role, administrator role or superuser
role.
6.1.1.21 FMT_MTD.1(AUTH) Management of TSF data
FMT_MTD.1.1(AUTH) The TSF shall restrict the ability to modify the user account settings for
the HTTP Access Control Policy, EJB Access Control Policy, JMS Access
Control Policy to
a) Specifying conﬁguration in conﬁguration ﬁle: authorized
administrators assigned to the maintainer role, deployer role,
administrator role or superuser role
Version: 2.0 Classiﬁcation: Public Page 36 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
b) Specifying conﬁguration in deployment descriptor: owner of the
application subject to the conﬁguration
.
Application Note: The access control policies are deﬁned in the conﬁguration ﬁle, or deployment
descriptor or other locations for each application as referenced in the application notes for each
FDP_ACC.1 iteration.
6.1.1.22 FPT_TRC.1 Internal TSF consistency
FPT_TRC.1.1 The TSF shall ensure that TSF data is consistent when replicated between parts
of the TOE.
FPT_TRC.1.2 When parts of the TOE containing replicated TSF data are disconnected, the
TSF shall ensure the consistency of the replicated TSF data upon reconnection
before processing any requests for
a) Identiﬁcation and authentication;
b) Access control;
c) Execution of operations for:
1. HTTP requests including Web Service requests;
2. EJB requests;
3. JMS requests;
4. Management requests subject to RBAC.
Application Note: This SFR covers the cluster communication that synchronizes the runtime state
of the diﬀerent cluster nodes.
6.1.2 JBoss EAP Management security
6.1.2.1 FDP_ACC.1(RBAC) Role-Based Access Control Policy
FDP_ACC.1.1(RBAC) The TSF shall enforce the Role-Based Access Control policy on
Subject: a user represented by a Principal or Subject object assigned
to a management role represented by the Group object;
Object:
● Target conﬁguration resource
● Target conﬁguration attribute for a resource
Operations:
● Model operations - read/write from the model which may imply
the starting and stopping of runtime services:
❍ Resource visibility
❍ Resource read
❍ Resource write
● RPC operations - operations aﬀecting the runtime state only by
either read or change runtime state without aﬀecting the model:
Version: 2.0 Classiﬁcation: Public Page 37 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
❍ Resource visibility
❍ read-runtime
❍ write-runtime
6.1.2.2 FDP_ACF.1(RBAC) Role-Based Access Control Functions
FDP_ACF.1.1(RBAC) The TSF shall enforce the Role-Based Access Control Policy to objects
based on the following:
a) Subject attributes: management roles;
b) Object attributes: sensitive ﬂag, application classiﬁcation, set of
objects, operations and additional activation constraints allowed
for the respective object referenced by a management role.
FDP_ACF.1.2(RBAC) The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed:
Access to the administrative object with the requested operation is
permitted if:
a) the requesting user is associated with a management role
containing the object and operation combination and is not
restricted by additional activation constraints.
FDP_ACF.1.3(RBAC) The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: none.
FDP_ACF.1.4(RBAC) The TSF shall explicitly deny access of subjects to objects based on the
following additional rules: none.
6.1.2.3 FMT_MSA.1(RBAC) Management of object security attributes
FMT_MSA.1.1(RBAC) The TSF shall enforce the Role-Based Access Control Policy to restrict
the ability to modify, delete the security attributes of the assignment
of objects and operations to management roles to authorized
administrators assigned to the administrator role or superuser role.
6.1.2.4 FMT_MSA.3(RBAC) Static attribute initialization
FMT_MSA.3.1(RBAC) The TSF shall enforce the Role-Based Access Control Policy to provide
restrictive default values for security attributes that are used to enforce the
SFP.
FMT_MSA.3.2(RBAC) The TSF shall allow the authorized administrators assigned to the
administrator role or superuser role to specify alternative initial values to
override the default values when an object or information is created.
Version: 2.0 Classiﬁcation: Public Page 38 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
6.1.2.5 FMT_SMF.1 Speciﬁcation of management functions
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions:
a) Management of access control policies;
b) Management of default value for JMS access control policy;
c) Management of default value for role-based access control policy.
6.1.2.6 FMT_SMR.2 Security roles
FMT_SMR.2.1 The TSF shall maintain the roles:
a) Administrative roles governing access according FDP_ACC.1(RBAC)
:
1. Monitor
2. Operator
3. Maintainer
4. Administrator
5. SuperUser
6. Deployer
7. Auditor
8. Additional roles created by a user with Administrator or
SuperUser roles
b) User roles governing access according to all other iterations of
FDP_ACC.1
FMT_SMR.2.2 The TSF shall be able to associate users with roles.
FMT_SMR.2.3 The TSF shall ensure that the conditions
a) The set of capabilities assigned to management roles allow the
modiﬁcation of security attributes for all objects accessible via
the administrative interfaces.
b) User roles allow access to application functions and mechanisms
as conﬁgured by the application owner.
are satisﬁed.
6.2 Security Functional Requirements Rationale
6.2.1 Security requirements coverage
The following table provides a mapping of SFR to the security objectives, showing that each security
functional requirement addresses at least one security objective.
Table 8: Mapping of security functional requirements to security objectives
Security Functional Requirements Objectives
FAU_GEN.1 O.AUDITING
Version: 2.0 Classiﬁcation: Public Page 39 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Security Functional Requirements Objectives
FAU_GEN.2 O.AUDITING
FDP_ACC.1(HTTP) O.ACCESS
FDP_ACC.1(EJB) O.ACCESS
FDP_ACC.1(JMS) O.ACCESS
FDP_ACF.1(HTTP) O.ACCESS
FDP_ACF.1(EJB) O.ACCESS
FDP_ACF.1(JMS) O.ACCESS
FDP_ROL_EXT.2 O.CONSISTENCY
FIA_ATD.1 O.ACCESS,
O.AUTHORIZATION,
O.ROLE
FIA_UAU.1 O.AUTHORIZATION
FIA_UID.1 O.AUTHORIZATION
FIA_USB.1 O.ACCESS,
O.AUTHORIZATION,
O.ROLE
FMT_MSA.1(EJB) O.ACCESS,
O.AUTHORIZATION
FMT_MSA.1(JMS) O.ACCESS,
O.AUTHORIZATION,
O.ROLE
FMT_MSA.3(WEB) O.ACCESS,
O.AUTHORIZATION
FMT_MSA.3(EJB) O.ACCESS,
O.AUTHORIZATION
FMT_MSA.3(JMS) O.ACCESS,
O.AUTHORIZATION,
O.ROLE
FMT_MTD.1(ACC) O.ACCESS
FMT_MTD.1(JMS) O.ACCESS,
O.ROLE
FMT_MTD.1(AUTH) O.ACCESS,
O.AUTHORIZATION,
O.ROLE
FPT_TRC.1 O.CONSISTENCY
FDP_ACC.1(RBAC) O.ROLE
FDP_ACF.1(RBAC) O.ROLE
FMT_MSA.1(RBAC) O.ROLE
FMT_MSA.3(RBAC) O.ROLE
FMT_SMF.1 O.ACCESS,
Version: 2.0 Classiﬁcation: Public Page 40 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Security Functional Requirements Objectives
O.AUTHORIZATION,
O.ROLE
FMT_SMR.2 O.ACCESS,
O.AUTHORIZATION,
O.ROLE
6.2.2 Security requirements suﬃciency
The following rationale provides justiﬁcation for each security objective for the TOE, showing that the
security functional requirements are suitable to meet and achieve the security objectives.
Table 9: Security objectives for the TOE rationale
Security Objectives Rationale
O.AUTHORIZATION The TSF must ensure that only authorized users gain access to the
TOE and its resources. Users authorized to access the TOE have to use
an identiﬁcation and authentication process [(FIA_UID.1, (FIA_UAU.1]. In
case of accessing the TOE using JBoss Remoting tunneled through TLS
and conﬁguring the TOE to perform certiﬁcate-based authentication, the
TOE only implements the identiﬁcation of the peer and relies on A.TLS
for the authentication aspect. To ensure authorized access to the TOE,
authentication data is protected [FIA_ATD.1]. Proper authorization for
subjects acting on behalf of users is also ensured [FIA_USB.1].
The management of the authorizations is speciﬁed in FMT_MTD.1(AUTH)
and FMT_SMF.1. FMT_SMR.2 deﬁnes the administration roles.
The default value for the JMS access control policy is modiﬁable as speciﬁed
with FMT_MSA.3(JMS) and FMT_MSA.1(JMS). Nobody is able to control which
default values are conﬁgured for the remaining access control mechanisms
[FMT_MSA.3(WEB), FMT_MSA.3(EJB) together with FMT_MSA.1(EJB)]. Please
note that the default values have an impact on the authorization, as a
permissive default value allows access to the resource without I&A.
O.ACCESS The diﬀerent access control mechanisms must have a deﬁned
scope of control [FDP_ACC.1(HTTP), FDP_ACC.1(EJB), FDP_ACC.1(JMS)].
The rules of the diﬀerent access control mechanisms must be
deﬁned [FDP_ACF.1(HTTP), FDP_ACF.1(EJB), FDP_ACF.1(JMS)]. The security
attributes of subjects used to enforce the diﬀerent access control
mechanisms must be deﬁned [FIA_ATD.1, FIA_USB.1].
The management of the access control settings is speciﬁed in
FMT_MTD.1(ACC), FMT_MTD.1(JMS), FMT_MTD.1(AUTH), and FMT_SMF.1.
FMT_SMR.2 deﬁnes the capability of maintaining user roles.
The default value for the JMS access control policy is modiﬁable as speciﬁed
with FMT_MSA.3(JMS) and FMT_MSA.1(JMS). Nobody is able to control which
default values are conﬁgured for the remaining access control mechanisms
[FMT_MSA.3(WEB), FMT_MSA.3(EJB) together with FMT_MSA.1(EJB)].
O.ROLE The role-based access control mechanism as deﬁned in FDP_ACC.1(RBAC)
and FDP_ACF.1(RBAC) ensures that the administrative operations and
administrative resources are accessible to authorized administrators
only when they belong to the role granted access. The capabilities
that can be assigned to roles are speciﬁed in each management
function [FMT_MSA.1(JMS), FMT_MSA.3(JMS)]; and [FMT_MTD.1(AUTH),
FMT_MTD.1(JMS)], which deﬁne operations accessible to authorized
Version: 2.0 Classiﬁcation: Public Page 41 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Security Objectives Rationale
administrators assigned to management roles. The security attributes of
roles mapped to subjects used to enforce the role-based access control
mechanisms must be deﬁned [FIA_ATD.1, FIA_USB.1].
The management of the role-based access control mechanism is deﬁned
in FMT_SMF.1, FMT_MSA.1(RBAC) and FMT_MSA.3(RBAC). Administrative
roles are deﬁned in FMT_SMR.2
O.AUDITING The events to be audited must be deﬁned [FAU_GEN.1], and must be
associated with the identity of the user that caused the event [FAU_GEN.2].
O.CONSISTENCY To ensure the consistency of user data, the TSF allows the deﬁnition of
transactions where each operation of the transaction must succeed for the
transaction to succeed or otherwise all operations already performed for
the transaction are rolled back [FDP_ROL_EXT.2]. In addition, to ensure the
consistency of TSF data when held in multiple locations of diﬀerent cluster
nodes, the TSF implements a cluster communication that updates the TSF
data in the appropriate cluster nodes when one node updates these TSF
data [FPT_TRC.1].
In addition, the following listing demonstrates the internal consistency of the SFRs:
Access Control policies
The diﬀerent iterations of FDP_ACC.1 require the existence of a diﬀerent access control for the
diﬀerent objects present in the TOE. The rules of these policies are described in the respective
iterations of FDP_ACF.1. To be eﬀective an access control mechanism requires users to be
properly identiﬁed and authenticated (as required by FIA_UID.1 and FIA_UAU.1), supported
by A.TLS, proper binding of subjects to users (as required by FIA_USB.1). FMT_MSA.3(WEB),
FMT_MSA.3(EJB), and FMT_MSA.3(JMS) deﬁne the default permissions for the diﬀerent access
control mechanisms. The management of access control settings speciﬁed in FMT_MSA.1(EJB),
FMT_MSA.1(JMS), and FMT_MTD.1(ACC) as well as account settings with FMT_MTD.1(AUTH)
support the access control policies.
Role-based Access Control for Management
FDP_ACC.1(RBAC) together with FDP_ACF.1(RBAC) specify the role-based access control policy
with the subject, objects and actions covered by the policy. This access control mechanism
is tied with roles in FMT_SMR.2. The role-based access control mechanism is conﬁgured as
deﬁned in FMT_MSA.1(RBAC) and FMT_MSA.3(RBAC). The diﬀerent iterations of FMT_MSA.1
and FMT_MSA.3 that allow management activities specify the authorization needed to perform
administration. To be eﬀective an access control mechanism requires users to be properly
identiﬁed and authenticated (as required by FIA_UID.1 and FIA_UAU.1), supported by A.TLS,
proper binding of subjects to users (as required by FIA_USB.1).
Audit
FAU_GEN.1 deﬁnes the events that the TOE is required to be able to audit. Those events are
related to other security functional requirements showing which event contributes to make
users accountable for their actions with respect to the requirement. FAU_GEN.2 requires that
the events are associated with the identity of the user that caused the event. Of course this
can only be done if the user is known (which may not be the case for failed login attempts).
Clustering
FPT_TRC.1 deﬁnes the replication mechanism to keep diﬀerent parts of the TOE (the diﬀerent
nodes of a cluster) consistent with each other. This SFR ensures that all TSF data, including
that required for the other SFRs are maintained consistently between the cluster nodes.
Version: 2.0 Classiﬁcation: Public Page 42 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Identiﬁcation and Authentication
As stated above Identiﬁcation and Authentication is required for useful access control policies
based on the identity and roles of individual users. FIA_UAU.1 and FIA_UID.1 require that users
are authenticated before they can perform actions on the TOE requiring the identity of the
user. Since the TOE implements threads acting on behalf of the user, FIA_USB.1 ensures that
those processes act within the limits deﬁned for the user they are acting for (unless they are
trusted to perform activities beyond the rights of the user). To allow the TOE to assign the
proper identiﬁers to subjects acting on behalf of users, FIA_ATD.1 deﬁnes various security
attributes for diﬀerent users.
Transaction Rollback
FDP_ROL_EXT.2 ensures that an automated rollback of failed transactions is performed by
the TOE. If the TOE identiﬁes that an operation belonging to a transaction fails, all operations
already performed for the transaction are rolled back to the state as if these operations never
happened.
6.2.3 Security requirements dependency analysis
The following table demonstrates the dependencies of the SFRs modeled in CC Part 2 and the extended
component deﬁnition in this Security Target, and how the SFRs for the TOE resolve those dependencies.
Table 10: TOE SFR dependency analysis
Security Functional
Requirement
Dependencies Resolution
FAU_GEN.1 FPT_STM.1 The security functional requirement
FAU_GEN.1 covering audit generation
depends on FPT_STM.1 for gathering
the date/time stamp for the audit
records. This dependency is uncovered
due to CC version 3.1 deﬁnition as this
version of the CC does not support the
deﬁnition of SFRs for the operational
environment. The TOE relies on the
underlying Java virtual machine to
provide the appropriate time stamp.
Hence, due to the deﬁnitions of CC 3.1
which does not allow the speciﬁcation of
SFRs for the operational environment,
this dependency is unresolved. The
functionality of providing a time stamp
is implemented by the underlying
Java virtual machine as deﬁned by
OE.SYSTEM.
FAU_GEN.1 FAU_GEN.1
FAU_GEN.2
FIA_UID.1 FIA_UID.1
FDP_ACC.1(HTTP) FDP_ACF.1 FDP_ACF.1(HTTP)
FDP_ACC.1(EJB) FDP_ACF.1 FDP_ACF.1(EJB)
FDP_ACC.1(JMS) FDP_ACF.1 FDP_ACF.1(JMS)
FDP_ACC.1 FDP_ACC.1(HTTP)
FDP_ACF.1(HTTP)
FMT_MSA.3 FMT_MSA.3(WEB)
Version: 2.0 Classiﬁcation: Public Page 43 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Security Functional
Requirement
Dependencies Resolution
FDP_ACC.1 FDP_ACC.1(EJB)
FDP_ACF.1(EJB)
FMT_MSA.3 FMT_MSA.3(EJB)
FDP_ACC.1 FDP_ACC.1(JMS)
FDP_ACF.1(JMS)
FMT_MSA.3 FMT_MSA.3(JMS)
FDP_ROL_EXT.2 No dependencies
FIA_ATD.1 No dependencies
FIA_UAU.1 FIA_UID.1 FIA_UID.1
FIA_UID.1 No dependencies
FIA_USB.1 FIA_ATD.1 FIA_ATD.1
[FDP_ACC.1 or FDP_IFC.1] FDP_ACC.1(EJB)
FMT_SMR.1 FMT_SMR.2
FMT_MSA.1(EJB)
FMT_SMF.1 FMT_SMF.1
[FDP_ACC.1 or FDP_IFC.1] FDP_ACC.1(JMS)
FMT_SMR.1 FMT_SMR.2
FMT_MSA.1(JMS)
FMT_SMF.1 FMT_SMF.1
FMT_MSA.1 The security functional requirement
FMT_MSA.3 covering the default values
for the diﬀerent access control policies
has a dependency on FMT_MSA.1
and FMT_SMR.1. The TOE does not
implement the management and
the respective protection of the
management of the access control
mechanisms. As speciﬁed in the
SFR, the TOE does not implement
an interface that allows altering of
the default settings for the diﬀerent
access control mechanisms. Thus, the
dependency on FMT_MSA.1 is not
fulﬁlled.
FMT_MSA.3(WEB)
FMT_SMR.1 As explained, the management of
the access control mechanism is not
required by the TOE. Hence, FMT_SMR.1
is appropriately excluded.
FMT_MSA.1 FMT_MSA.1(EJB)
FMT_MSA.3(EJB)
FMT_SMR.1 FMT_SMR.2
FMT_MSA.1 FMT_MSA.1(JMS)
FMT_MSA.3(JMS)
FMT_SMR.1 FMT_SMR.2
FMT_SMR.1 FMT_SMR.2
FMT_MTD.1(ACC)
FMT_SMF.1 FMT_SMF.1
Version: 2.0 Classiﬁcation: Public Page 44 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Security Functional
Requirement
Dependencies Resolution
FMT_SMR.1 FMT_SMR.2
FMT_MTD.1(JMS)
FMT_SMF.1 FMT_SMF.1
FMT_SMR.1 FMT_SMR.2
FMT_MTD.1(AUTH)
FMT_SMF.1 FMT_SMF.1
FPT_TRC.1 FPT_ITT.1 The security functional requirement
FPT_TRC.1 covering the cluster
communication has a dependency on
FPT_ITT.1. The TOE does not rely
on the technical implementation of
the protection of the data channels
between diﬀerent TOE instances as
the network utilized for the cluster
communication covered by FPT_TRC.1
is physically separated from any other
network. In addition, the base operating
system is conﬁgured to not permit any
routing from any attached network into
the physically separated network used
for the cluster communication. Thus,
the requirement of FPT_ITT.1 is covered
with non-technical means.
FDP_ACC.1(RBAC) FDP_ACF.1 FDP_ACF.1(RBAC)
FDP_ACC.1 FDP_ACC.1(RBAC)
FDP_ACF.1(RBAC)
FMT_MSA.3 FMT_MSA.3(RBAC)
[FDP_ACC.1 or FDP_IFC.1] FDP_ACC.1(RBAC)
FMT_SMR.1 FMT_SMR.2
FMT_MSA.1(RBAC)
FMT_SMF.1 FMT_SMF.1
FMT_MSA.1 FMT_MSA.1(RBAC)
FMT_MSA.3(RBAC)
FMT_SMR.1 FMT_SMR.2
FMT_SMF.1 No dependencies
FMT_SMR.2 FIA_UID.1 FIA_UID.1
6.3 Security Assurance Requirements
The security assurance requirements (SARs) for the TOE are deﬁned in [CC] part 3 for the Evaluation
Assurance Level 2, augmented by ALC_FLR.3.
The following table shows the SARs, and the operations performed on the components according to CC
part 3: iteration (Iter.), reﬁnement (Ref.), assignment (Ass.) and selection (Sel.).
Version: 2.0 Classiﬁcation: Public Page 45 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Table 11: SARs
Operations
Security
Assurance
Class
Security Assurance Requirement Source
Iter. Ref. Ass. Sel.
ADV_ARC.1 Security architecture description CC Part 3 No No No No
ADV_FSP.2 Security-enforcing functional
speciﬁcation
CC Part 3 No No No No
ADV
Development
ADV_TDS.1 Basic design CC Part 3 No No No No
AGD_OPE.1 Operational user guidance CC Part 3 No No No No
AGD Guidance
documents
AGD_PRE.1 Preparative procedures CC Part 3 No No No No
ALC_CMC.2 Use of a CM system CC Part 3 No No No No
ALC_CMS.2 Parts of the TOE CM coverage CC Part 3 No No No No
ALC_DEL.1 Delivery procedures CC Part 3 No No No No
ALC Life-cycle
support
ALC_FLR.3 Systematic ﬂaw remediation CC Part 3 No No No No
ASE_INT.1 ST introduction CC Part 3 No No No No
ASE_CCL.1 Conformance claims CC Part 3 No No No No
ASE_SPD.1 Security problem deﬁnition CC Part 3 No No No No
ASE_OBJ.2 Security objectives CC Part 3 No No No No
ASE_ECD.1 Extended components deﬁnition CC Part 3 No No No No
ASE_REQ.2 Derived security requirements CC Part 3 No No No No
ASE Security
Target
evaluation
ASE_TSS.1 TOE summary speciﬁcation CC Part 3 No No No No
ATE_COV.1 Evidence of coverage CC Part 3 No No No No
ATE_FUN.1 Functional testing CC Part 3 No No No No
ATE Tests
ATE_IND.2 Independent testing - sample CC Part 3 No No No No
AVA Vulnerability
assessment
AVA_VAN.2 Vulnerability analysis CC Part 3 No No No No
6.4 Security Assurance Requirements Rationale
The evaluation assurance level commensurate with the threat environment that is experienced by
typical consumers of the TOE. In addition, the evaluation assurance level augmented with ALC_FLR.3
commensurate with the augmented ﬂaw remediation capabilities oﬀered by the developer beyond
those required by the evaluation assurance level.
Version: 2.0 Classiﬁcation: Public Page 46 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
7 TOE Summary Speciﬁcation
7.1 TOE Security Functionality
The following section explains how the security functions are implemented. The diﬀerent TOE security
functions cover the various SFR classes.
The primary security features of the TOE are:
● Access Control
● Role-based access control for management interfaces
● Audit
● Clustering
● Identiﬁcation and Authentication
● Transaction Rollback
7.1.1 Access Control
Using access control, the TOE is able to restrict access for the following request types with the following
access control mechanisms:
● HTTP: URLs and paths provided with URLs can be protected from access by subjects:
❍ Obtain the names of the roles allowed to access the URL. The role names are
determined by the “security-constraint” elements deﬁned for the invoked URL and
optionally the HTTP request method as part of the HTTP deployment descriptor
or the "@ServletSecurity" annotation. Note, JBoss EAP supports all HTTP request
methods speciﬁed in the RFCs and custom methods. In addition to the speciﬁcation
of the URL and HTTP request method, the access control mechanism can optionally
require cryptographic protection of the user’s connection (either none, integrity-
protected, conﬁdentiality-protected).
● EJB: EJBs and associated method names can be protected from being called by subjects:
❍ Obtain the names of the roles allowed to access the EJB method from the EJB
container. The role names are determined by the “role-name” elements of all
“method-permission” elements containing the invoked method as deﬁned in the EJB
deployment descriptor or annotation.
❍ If no roles have been assigned, or the method is speciﬁed in an exclude-list element,
then access to the method is denied. Otherwise, the doesUserHaveRole method is
invoked to see if the caller has one of the assigned role names. This method iterates
through the role names and checks if the authenticated user’s Subject Roles group
contains role with the given name. Access is allowed if any role name is a member
of the Roles group. Access is denied if none of the role names are members.
● JMS: Message queue destinations and topic destinations can be protected from access by
subjects:
❍ Obtain the names of the roles allowed to access the message queue destination or
topic destination. The role names are determined by the “security-setting” elements
deﬁned for the message queue destination or topic destination in the JBoss EAP
system conﬁguration ﬁle.
❍ Access to the message queue and topic destinations is controlled using the following
permissions:
➤ create-durable-queue allows the role to create a durable queue under
matching addresses.
Version: 2.0 Classiﬁcation: Public Page 47 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
➤ delete-durable-queue allows the role to delete a durable queue under
matching addresses.
➤ create-non-durable-queue allows the role to create a non-durable queue
under matching addresses.
➤ delete-non-durable-queue allows the role to delete a non-durable queue
under matching addresses.
➤ send allows the role to send a message to matching addresses.
➤ consume allows the role to consume a message from a queue bound
to matching addresses. manage allows the role to invoke management
operations by sending management messages to the management address.
❍ The TSF permits to specify a global default access control rule which governs the
access to the destinations if no access control rule is speciﬁed for the individual
destination. If no roles have been assigned, or the destinations are not covered
by an access control rule (including no global access control rule is speciﬁed),
then access to the method is denied. Otherwise, the doesUserHaveRole method is
invoked to see if the caller has one of the assigned role names. This method iterates
through the role names and checks if the authenticated user's Subject Roles group
contains the required role name. Access is allowed if any role name is a member of
the Roles group. Access is denied if none of the role names are members.
The above mentioned network protocols tunnel the client requests to the TOE. After the TOE performed
the I&A and access control checks, the request is forwarded to the intended application. As the TOE
only uses the credential information from the network request, only the aspect of communicating the
user credentials as well as the requested object and the request type is relevant for the enforcement
of the access control policy.
The TOE allows independent management of the access control policy for each application and for
each policy. The mentioned deployment descriptors, and annotations can be used by authorized
administrators (and developers which belong to the category of authorized administrators as speciﬁed
in A.DEVEL) to conﬁgure the access control. Note that the TOE provides the interfaces for managing
the access control policies. However, it does not restrict the use of the interfaces as direct access to
the JBoss EAP system conﬁguration ﬁle is technically possible if a user can log into the host system
and has write access to that ﬁle - based on A.PROTECT the environment ensures that only authorized
administrators are allowed to access the host system.
This security function covers all SFRs mapped to O.ACCESS.
7.1.2 Role-based Access Control for Management Interfaces
The management interfaces of JBoss EAP, the command line interface as well as the web-based
administrative interface, allow access to the JBoss EAP system conﬁguration to manage all conﬁgurable
aspects of JBoss EAP. Administrators can access general system aspects, such as network port
conﬁgurations, and container conﬁguration. In addition, conﬁguration aspects for services oﬀered by
containers are managed as well.
The conﬁguration aspects of applications, such as the application access control, are addressed with
the deployment descriptors shipped with the application. Therefore, this conﬁguration aspect is not
accessible via the administrative interface.
The administrative interfaces can be bound to a speciﬁc network interface. This allows the maintenance
of an admin LAN to prevent untrusted users from technically accessing the interfaces. In order for an
administrator to interact with administrative interfaces, he must log in. The administrative accounts
are maintained separately from other user accounts.
Version: 2.0 Classiﬁcation: Public Page 48 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Each action on an object that an administrative user can perform is subject to a role-based access
control mechanism. The actions are classiﬁed into:
● Model operations - the main function of these is to read/write from the model, although there
will often be associated runtime services started/stopped as a consequence.
● RPC operations - these invoke some runtime aﬀecting runtime state only. This may either
read runtime state or change it. The model is not aﬀected.
The objects are classiﬁed based on the following:
● a resource;
● an attribute residing in a resource.
A set of object-action capabilities are mapped to a management role. This mapping deﬁnes the allowed
access for this management role. A set of predeﬁned roles is shipped with the TOE and is available
after installation. The following table speciﬁes the preconﬁgured roles.
Table 12: Role-based access control pre-conﬁgured management roles
Role Description
Monitor The Monitor role has the fewest permissions and restricts the user to viewing the
conﬁguration and the current state. The monitor role does not have permission to
modify the server conﬁguration, or access sensitive data or operations.
Operator The Operator role extends the Monitor role by adding the ability to modify the
runtime state of the server, but not the persistent conﬁguration. For example,
the operator can start or stop servers, and pause and resume JMS destinations.
The operator role does not have permission to modify the server conﬁguration, or
access sensitive data or operations.
Maintainer The Maintainer role has access to view and modify the runtime state and all
conﬁgurations except sensitive data and operations. The Maintainer role has
almost complete access to administer the server without giving those users access
to passwords and other sensitive information.
Administrator The Administrator role has unrestricted access to all resources and operations on
the server except the audit logging system. The Administrator role has access to
sensitive data and operations, and can also conﬁgure the access control system.
SuperUser The SuperUser role does not have any restrictions, and it has complete access
to all resources and operations of the server, including the audit logging system.
If RBAC is disabled, all management users have permissions equivalent to the
SuperUser role.
Deployer The Deployer role has the same permissions as the Monitor, but it can modify the
conﬁguration and state for deployments and any other resource type enabled as
an application resource.
Auditor The Auditor role has all the permissions of the Monitor role and can also view, but
not modify, sensitive data. The Auditor role has full access to the audit logging
system.
A role is a named set of permissions. Those permissions include constraints (e.g., the read permissions
for the Monitor role is constrained to non-sensitive actions and targets).
Redeﬁnition of the permissions and constraints associated with the above mentioned standard roles
is not permitted.
A limited form of creation of new roles is allowed. These new roles are equivalent to the standard
roles, but with an additional constraint applied to all permissions, i.e., the target must be related to
a particular host or server group.
Version: 2.0 Classiﬁcation: Public Page 49 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
The JBoss EAP system conﬁguration ﬁle is either domain.xml or standalone.xml depending on the
startup mode of JBoss EAP or a conﬁguration ﬁle speciﬁed via a command line option. Any administrative
operations are stored in that conﬁguration ﬁle. The administrative interfaces are an in-memory image
of the data stored in the XML ﬁle. Once the in-memory image is modiﬁed, the modiﬁed XML ﬁle is stored.
The role-based access control mechanism can only be enforced if the administrator accesses the
JBoss EAP system conﬁguration via the above mentioned interfaces. It is technically possible that an
administrator has shell access to the host. In this case, the underlying operating system may grant
direct read or write access to that JBoss EAP system conﬁguration ﬁle. Such access would imply that
the role-based access control mechanism is not enforced. However, as assumed in A.PROTECT, the
host is located in a protected environment, where direct access to the JBoss EAP system conﬁguration
ﬁle is not allowed.
This security function covers all SFRs mapped to O.ROLE.
7.1.3 Audit
The TOE implements an audit mechanism that allows generating audit records for security-relevant
events concerning access control. The administrative user is able to select the events which are to
be audited.
The audit facility is based on the log4j mechanism which is integrated into the TOE. Log4j has three
main components: loggers, appenders and layouts. These three types of components work together
to enable developers to log messages based on message type and level, and to control how these
messages are formatted and where they are reported at runtime.
The audit information is recorded in text ﬁles which can be reviewed using tools from the underlying
operating system, such as pagers or editors.
This security function covers all SFRs mapped to O.AUDITING.
7.1.4 Clustering
A cluster is a set of nodes. In a JBoss EAP cluster, a node is a JBoss EAP server instance. Thus, to build
a cluster, several JBoss EAP instances have to be grouped together (known as a "partition").
Clustering allows the execution of applications on several parallel servers (a.k.a cluster nodes). Two
diﬀerent cluster concepts are possible with JBoss EAP: a failover cluster and a load-distribution cluster.
In both cases, the server state is distributed across diﬀerent servers, and even if any of the servers
fails, the application is still accessible via other cluster nodes.
The cluster communication establishes the data consistency between the diﬀerent cluster nodes of the
following information:
● Replication of the state of a node covers the replication of HTTP sessions, EJB session beans,
EJB entity beans, as well as Hibernate persistence objects (distributed state replication
service using Inﬁnispan).
JGroups and Inﬁnispan provide the underlying communication, node replication and caching
services, for JBoss EAP clusters. Those services are conﬁgured as MBeans. There is a set of
Inﬁnispan and JGroups MBeans for each type of clustering applications (e.g., the Stateful
Session EJBs, the distributed entity EJBs, etc.).
The JGroups framework provides services to enable peer-to-peer communications between
nodes in a cluster. It is built on top a stack of network communication protocols that provide
transport, discovery, reliability and failure detection, and cluster membership management
services.
Version: 2.0 Classiﬁcation: Public Page 50 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Inﬁnispan provides distributed cache and state replication services for the JBoss EAP cluster.
A JBoss EAP cluster can have multiple Inﬁnispan MBeans, one for HTTP session replication,
one for stateful session beans, one for cached entity beans, etc.
● Replication of the state of a node covering the replication of HTTP sessions.
● Replication of JMS queues.
JBoss Messaging clusters JMS queues and topics transparently across the cluster. Messages
sent to a distributed queue or topic on one node are consumable on other nodes.
JBoss EAP does not perform an automated replication of the JNDI state. When applications deﬁning JNDI
resources are replicated to the diﬀerent cluster nodes, they are newly deployed at the nodes. With the
deployment, the JNDI resources are created similarly to a regular deployment. System conﬁguration
changes that involve modiﬁcations of JNDI resources are replicated to the cluster nodes and applied
similarly to a local reconﬁguration. With these approaches, the JNDI registry maintaining the JNDI
mappings are managed consistently between the diﬀerent cluster nodes. As JNDI does not maintain
a state other than the JNDI registry, the approach is suﬃcient to ensure cluster-wide consistency of
the JNDI service.
This security function covers the FPT_TRC.1 SFR mapped to O.CONSISTENCY.
7.1.5 Identiﬁcation and authentication
Users are assigned unique user identiﬁers which are used as the basis for access control decisions and
auditing. The TOE authenticates the claimed identity of the user before allowing the user to perform any
further TSF-mediated actions. The TOE internally maintains the identiﬁer associated with the thread
spawned for the user after a successful authentication.
The TOE provides diﬀerent identiﬁcation and authentication mechanisms for the diﬀerent request
types:
● HTTP and Web Services: BASIC, FORM, DIGEST and CLIENT_CERT authentication.
● EJB: username and password-based authentication, client certiﬁcate based identiﬁcation.
● JMS: username and password-based authentication.
For identiﬁcation and authentication using a client certiﬁcate, the TOE uses the underlying TLS channel
established by the operational environment. The underlying TLS protocol performs the certiﬁcate
validation of the client certiﬁcate. The EJB component of the TOE queries the TLS session for the DN
part of the certiﬁcate to identify the user. That DN information is used to set up the role mapping and
create a principal in the TOE. Therefore, the TOE relies on the TLS implementation in the operational
environment to perform authentication by enforcing the validation of the client certiﬁcate.
The security framework used by the TOE deﬁnes a set of small components (security domains, security
realms, mappers, etc.) to assemble a full security policy. The components described below are related
to the Identiﬁcation and Authentication security functionalities.
● A Security Domain is the representation of a security policy which is backed by one or more
security realms and a set of resources that perform transformations.
● A Security Identity is the representation of the current user, which is based on the raw
AuthorizationIdentity and its associated roles and permissions within a Security Domain.
● Security realms provide access to an identity store and are used to obtain credentials.
These credentials allow authentication mechanisms to obtain the raw AuthorizationIdentity
for performing authentication. They also allow authentication mechanisms to perform
veriﬁcation when doing validation of evidence. There may have more than one security
realm in a Security Domain.
The TOE supports diﬀerent identity stores by referencing diﬀerent security realms:
Version: 2.0 Classiﬁcation: Public Page 51 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
● File based authentication using the properties-realm security realm.
● Certiﬁcate based authentication using the key-store-realm security realm.
● LDAP based authentication using the ldap-realm security realm.
● Database based authentication using the jdbc-realm security realm.
The TOE allows the management of the authorization independently for each application and service.
The mentioned deployment descriptors, and annotations can be used by authorized administrators
(and developers which belong to the category of authorized administrators as speciﬁed in A.DEVEL) to
conﬁgure the I&A mechanism. Note that the TOE provides the interfaces for managing the I&A policy.
However, it does not restrict the use of the interfaces to authorized administrators. These settings are
stored in the JBoss EAP system conﬁguration. This conﬁguration ﬁle could be accessed by users with
write permissions when having access to the host system. Thus, the host system ensures that only
authorized administrators are allowed to access the host system as assumed by A.PROTECT.
This security function covers all SFRs mapped to O.AUTHORIZATION.
7.1.6 Transaction Rollback
JBoss EAP includes a fast in-VM implementation of a JBoss Transactions compatible transaction manager
that is used as the default transaction manager. A transaction is deﬁned as a unit of work containing one
or more operations involving one or more shared resources having ACID properties. ACID is an acronym
for Atomicity, Consistency, Isolation and Durability, the four important properties of transactions. The
meanings of these terms are:
● Atomicity: A transaction must be atomic. This means that either all the work done in the
transaction must be performed, or none of it must be performed. Doing part of a transaction
is not allowed.
● Consistency: When a transaction is completed, the system must be in a stable and
consistent condition.
● Isolation: Diﬀerent transactions must be isolated from each other. This means that the
partial work done in one transaction is not visible to other transactions until the transaction
is committed, and that each process in a multi-user system can be programmed as if it was
the only process accessing the system.
● Durability: The changes made during a transaction are made persistent when it is
committed. When a transaction is committed, its changes will not be lost, even if the server
crashes afterwards.
In traditional ACID transaction systems, transactions are short lived, resources (such as databases)
are locked for the duration of the transaction and participants have a high degree of trust with each
other. With the advent of the Internet and web services, the scenario that is now emerging requires
involvement of participants unknown to each other in distributed transactions. JBoss Transactions adds
native support for web services transactions by providing all of the components necessary to build
interoperable, reliable, multi-party, web services-based applications with the minimum of eﬀort. The
programming interfaces are based on the Java API for XML Transactioning (JAXTX) and the product
includes protocol support for the WS-AtomicTransaction and WS-BusinessActivity speciﬁcations. JBoss
EAP is designed to support multiple coordination protocols.
JBoss EAP supports both local and distributed transactions. A transaction is considered to be distributed
if it spans multiple process instances, i.e., virtual machines (VMs). Typically a distributed transaction will
contain participants that are located within multiple VMs but the transaction is coordinated in a separate
VM (or co-located with one of the participants). If the deployment requires distributed transactions then
the web service transactions component can be utilized, which uses SOAP/HTTP.
This security function covers the FDP_ROL_EXT.2 SFR mapped to O.CONSISTENCY.
Version: 2.0 Classiﬁcation: Public Page 52 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
8 Abbreviations, Terminology, and References
8.1 Abbreviations
ACL
Access Control List
API
Application Programming Interface
EJB
Jakarta Enterprise Beans
HA
High Availability
HTTP
Hypertext Transfer Protocol
IIOP
Internet Inter-ORB Protocol
J2EE
See Java EE
JAAS
Java Authentication and Authorization Services
JATAX
Java API for XML Transationing
Jakarta EE
Jakarta Enterprise Edition
Java EE
Java Enterprise Edition
JAX-RS
Java API for RESTful Web Services
JDBC
Java Database Connectivity
JDK
Java Development Kit
JMS
Jakarta Messaging Service
JMX
Java Management Extensions
JNDI
Java Naming and Directory Interface
JRE
Java Runtime Environment
Version: 2.0 Classiﬁcation: Public Page 53 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
JRMP
Java Remote Method Protocol
JVM
Java Virtual Machine
LDAP
Lightweight Directory Access Protocol
ORB
Object Request Broker
POJO
Plain Old Java Object
RBAC
Role-Based Access Control
SAML
Security Assertion Markup Language
SASL
Simple Authentication and Security Layer
SFR
Security Functional Requirement
SOAP
Simple Object Access Protocol
SSL
Secure Sockets Layer
SSO
Single Sign-on
ST
Security Target
TCP/IP
Transmission Control Protocol / Internet Protocol
TLS
Transport Layer Security
TOE
Target of Evaluation
TSF
TOE Security Functionality
VM
Virtual Machine
VPN
Virtual Private Network
XML
Extensible Markup Language
Version: 2.0 Classiﬁcation: Public Page 54 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
8.2 Terminology
This section contains deﬁnitions of technical terms that are used with a meaning speciﬁc to this
document. Terms deﬁned in the [CC] are not reiterated here, unless stated otherwise.
Administrative User
This term refers to a user in one of the deﬁned management roles of a JBoss EAP system.
The TOE deﬁnes a set of management roles where each role has speciﬁc administrative
authorities. Splitting the administrative authorities among diﬀerent roles allows for a
more controlled operational environment without the need for a single user to have all
administrative authorities.
Authentication Data
This includes the password and X.509 certiﬁcates for each user of the product. Authentication
mechanisms using other authentication data are not supported in the evaluated conﬁguration.
Credentials
A credential may contain information used to authenticate the subject to new services. Such
credentials include passwords, Kerberos tickets, and public key certiﬁcates. Credentials might
also contain data that simply enables the subject to perform certain activities. Cryptographic
keys, for example, represent credentials that enable the subject to sign or encrypt data.
Data
Arbitrary bit sequences in computer memory or on storage media.
Group
After a user is successfully identiﬁed and authenticated, JBoss EAP instantiates a “Group” Java
object containing the groups the authenticated subject is associated with.
Information
Any data held within a JBoss EAP instance, including data in transit between systems.
JBoss Container
A JBoss EAP container, or in short container, is a part of JBoss EAP that provides services
to user-written programs. For example, the EJB functionality is implemented by the EJB
container, the JSP/servlet functionality is implemented by the JBossWeb container. The JBoss
EAP architecture implements various functional aspects as self-contained containers which
can be selectively enabled.
Named Object
In JBoss EAP, those objects that are subject to access control. This includes all objects except
memory objects. Please note, named objects are not to be mixed with the implementation of
Java objects.
Object
For JBoss EAP, objects are deﬁned by the diﬀerent iterations of FDP_ACC.1.
Principal
A Principal is an identity associated to a Subject, which may have many Principals. Once a
Subject is authenticated, it is populated with its Principals. For example, a person may have
a name Principal ("John Doe") and a SSN Principal ("123-45-6789"), which distinguish it from
other subjects.
Product
The term product is used to deﬁne software components that comprise the JBoss Enterprise
Application Platform.
Version: 2.0 Classiﬁcation: Public Page 55 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Role
A role represents a set of actions that an authorized user, upon assuming the role, is allowed
to perform.
Subject
To authorize access to resources, applications ﬁrst need to authenticate the source of the
request. The JAAS framework deﬁnes the term subject to represent the source of a request.
A subject may be any entity, such as a person or a service. A Subject may also own security-
related attributes, which are referred to as credentials.
Target Of Evaluation (TOE)
The TOE is deﬁned as the JBoss EAP application server, running and tested on the hardware,
operating systems and Java virtual machines speciﬁed in this Security Target.
User
Any individual/person who has a unique user identiﬁer and who interacts with the JBoss EAP
product. Unauthorized users do not possess a valid user identiﬁer.
User Security Attributes
Deﬁned by functional requirement FIA_ATD.1, every user is associated with a number of
security attributes which allow the TOE to enforce its security functions on this user.
8.3 References
Common Criteria for Information Technology Security Evaluation
Version 3.1R5
Date April 2017
Location http://www.commoncriteriaportal.org/files/ccfiles/CCPART1V3.1R5.pdf
Location http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R5.pdf
CC
Location http://www.commoncriteriaportal.org/files/ccfiles/CCPART3V3.1R5.pdf
Jakarta EE Platform Version 10
Date 2022-09-13
JAKARTA_EE
10
Location https://jakarta.ee/specifications/platform/10/
Red Hat JBoss EAP Common Criteria Certiﬁcation 8.1 - Common Criteria
Conﬁguration Guide
Version SHA-256 value:
(94492a78087a6c4fb5a6d4a90745272559f8fc8e2f44dc797416f726b0688232)
Date 2025-12-23
JBEAP-CCGU
IDE
Location https://docs.redhat.com/en/documentation/jboss_enterprise_application_platfo
rm_common_criteria_certification/8.1/pdf/common_criteria_configuration_guid
e
Red Hat JBoss Enterprise Application Platform 8.1 - Conﬁguration Guide
Version SHA-256 value:
(59566f1c48abd0c5bd7d0c33990c1b779d944a8133430ac0b991382b1e4dfb72)
Date 2025-08-28
JBEAP-CG
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/8.1/pdf/configuration_guide
JBEAP-CM Red Hat JBoss EAP 7.4 - Conﬁguring Messaging
Version: 2.0 Classiﬁcation: Public Page 56 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Version SHA-256 value:
(cac0a11dc4cde76dc20a38c1c37ca17537bb25f62513b16e10efd84e8356ca63)
Date 2024-01-17
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/7.4/pdf/configuring_messaging
Red Hat JBoss EAP 8.1 - Secure storage of credentials in JBoss EAP
Version SHA-256 value:
(03d6d98da9b9f7144c46b71ﬀ53921d8ac95558ccc72c7f8415841c715be580a)
Date 2025-08-28
JBEAP-CRED
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/8.1/pdf/secure_storage_of_credentials_in_jboss_eap
Red Hat JBoss EAP 7.4 - How to Conﬁgure Server Security
Version SHA-256 value:
(357317ce3d300df3b96189494bc5363ce9231687c11913ee9aa3bf1d862e0578)
Date 2024-01-17
JBEAP-CSS
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/7.4/pdf/how_to_configure_server_security
Red Hat JBoss EAP 7.4 - Developing Jakarta Enterprise Beans Applications
Version SHA-256 value:
(3735a3ccd8e8776fc73b655be99d92419ce6c81bf38a02f968a0416828f13822)
Date 2024-01-17
JBEAP-DEJB
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/7.4/pdf/developing_jakarta_enterprise_beans_applications
Red Hat JBoss EAP 7.4 - Development Guide
Version SHA-256 value:
(0cc637ca24e5db957c502b2005d49ca6f42dddc78d20a27f47979d387d266a66)
Date 2024-01-17
JBEAP-DG
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/7.4/pdf/development_guide
Red Hat JBoss EAP 7.4 - Developing Hibernate Applications
Version SHA-256 value:
(d8d9145c0de5fc843f1787db051167c31bc20de269bae4d3c66a33ac65e863a5)
Date 2024-01-17
JBEAP-DHA
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/7.4/pdf/developing_hibernate_applications
Red Hat JBoss EAP 7.4 - Developing Web Services Applications
Version SHA-256 value:
(303026c0ae2b402d504744f2e30f1385b142dcdd9587696e6f8934a1dd8d7a10)
Date 2024-01-17
JBEAP-DWSA
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/7.4/pdf/developing_web_services_applications
Red Hat JBoss EAP 8.1 - Getting Started with Red Hat JBoss Enterprise
Application Platform
Version SHA-256 value:
(f702e2339500e2c99d9ba732b0fc7c147593d1a78a7bae65fbd43c3e981fa5aa)
JBEAP-GS
Date 2025-08-28
Version: 2.0 Classiﬁcation: Public Page 57 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/8.1/pdf/getting_started_with_red_hat_jboss_enterprise_application
_platform
Red Hat JBoss EAP 8.1 - Getting started with developing applications for JBoss
EAP deployment
Version SHA-256 value:
(d30aba056c28373a5f5418201d4acb91892bbbc4e33e62a59af7357ae7bad916)
Date 2025-08-28
JBEAP-GSD
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/8.1/pdf/getting_started_with_developing_applications_for_jboss_e
ap_deployment
Red Hat JBoss EAP 8.1 - Red Hat JBoss Enterprise Application Platform
Installation Methods
Version SHA-256 value:
(9a02b67bb154a28953b5d09ea94b2a6f938137d97ﬀ28dd7c648555dc7a40930)
Date 2025-08-28
JBEAP-IG
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/8.1/pdf/red_hat_jboss_enterprise_application_platform_installation
_methods
Red Hat JBoss EAP 8.1 - Introduction to Red Hat JBoss Enterprise Application
Platform
Version SHA-256 value:
(ﬀ879e0de9977d8139ﬀd5e31e881660a547449d8860768abd91371f45324689)
Date 2025-08-28
JBEAP-INTRO
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/8.1/pdf/introduction_to_red_hat_jboss_enterprise_application_plat
form
Red Hat JBoss EAP 8.1 - Securing applications and management interfaces
using an identity store
Version SHA-256 value:
(ddc5b2abb0a4732d49bfb8d34922a915ecbb8a8fb0096600e3427f35bbd8936b)
Date 2025-08-28
JBEAP-IS
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/8.1/pdf/securing_applications_and_management_interfaces_using
_an_identity_store
Red Hat JBoss Enterprise Application Platform 8.0.0.GA public API
Version 8.0.0.GA
Date (not applicable)
JBEAP-JD
Location https://access.redhat.com/webassets/avalon/d/red_hat_jboss_enterprise_appli
cation_platform/8.0/javadocs
Red Hat JBoss EAP 7.4 - Login Module Reference
Version SHA-256 value:
(840331d670329943ded687578fa8471157a44aca8d68272b0e6ee6ed2a321fd2)
Date 2024-01-17
JBEAP-LMR
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/7.4/pdf/login_module_reference
Version: 2.0 Classiﬁcation: Public Page 58 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Red Hat JBoss EAP 8.1 - Getting Started with Management Console
Version SHA-256 value:
(356c5c7840b0741c8f67f968eba82c0f55d5c7681ba2aﬀ21c3b97d973c2560b)
Date 2025-08-28
JBEAP-MC
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/8.1/pdf/getting_started_with_management_console
Red Hat JBoss EAP 7.4 - Management CLI Guide
Version SHA-256 value:
(778e806d19724605bdb7b037eacfbb56d54713974af2f413c4ﬀ582807b0b5bf)
Date 2024-01-17
JBEAP-MCG
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/7.4/pdf/management_cli_guide
Red Hat JBoss EAP 8.1 - Securing applications and management interfaces
using multiple identity stores
Version SHA-256 value:
(13b7ba6d8964625a502cd50507028772cac769eb08ef10c9e57420c7c30d5f27)
Date 2025-08-28
JBEAP-MIS
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/8.1/pdf/securing_applications_and_management_interfaces_using
_multiple_identity_stores
Red Hat JBoss EAP 7.4 - Managing Transactions on JBoss EAP
Version SHA-256 value:
(a93d157eddfe95a3dcb21a9f9c77b05e1ab1fc24d1a7e23eba332aa24e33f2a9)
Date 2024-01-17
JBEAP-MT
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/7.4/pdf/managing_transactions_on_jboss_eap
Red Hat JBoss EAP 7.4 - Security Architecture
Version SHA-256 value:
(ceaaac8208f4cbdb1f03705b0f77a714c2c670922f6c85767e2e51c2792c9ad7)
Date 2024-02-08
JBEAP-SA
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/7.4/pdf/security_architecture
Red Hat JBoss EAP 8.1 - Using single sign-on with JBoss EAP
Version SHA-256 value:
(4c414c8d0efbc5666bfc2defa6a35ccafa9398c501c12abﬀdc3f19faeddcc0b)
Date 2025-08-28
JBEAP-SSO
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/8.1/pdf/using_single_sign-on_with_jboss_eap
Red Hat JBoss EAP 8.1 - Conﬁguring SSL/TLS in JBoss EAP
Version SHA-256 value:
(64d4c1955f0cb479c2588a5b9c2934e39d0ae79df6c5244ﬀbf905cdb3cb483b)
Date 2025-08-28
JBEAP-TLS
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/8.1/pdf/configuring_ssltls_in_jboss_eap
Version: 2.0 Classiﬁcation: Public Page 59 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security
Red Hat, Inc.
JBoss EAP 8 Security Target
Red Hat JBoss EAP 8.1 - Updating Red Hat JBoss Enterprise Application
Platform
Version SHA-256 value:
(d4d7b8f5869663e3dea5a8d9abdb254b1baf721e9937fa45eec5e4810b7744b6)
Date 2025-08-28
JBEAP-UPDT
Location https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_applicati
on_platform/8.1/pdf/updating_red_hat_jboss_enterprise_application_platform
Red Hat Customer Portal
Date (not applicable)
RHCP
Location https://access.redhat.com
Version: 2.0 Classiﬁcation: Public Page 60 of 60
Last update: 2026-01-30 Copyright ©2025 by Red Hat and atsec information security