Chapter 7. Overview of the Security Functions

7.1. Access Control

JBoss EAP 7 has access control mechanisms to restrict access for the following request types:

  • HTTP: URLs and paths provided with URLs, as well as Plain Old Java Objects (POJOs) deployed as servlets and session Beans, 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 defined 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 specified in the RFCs and custom methods.

      In addition to the specification of the URL and HTTP request method, the access control mechanism can optionally require cryptographic protection of the user’s connection, which can be either none, integrity-protected or confidentiality-protected.

  • EJB: EJBs and associated method names can be protected from invocation 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 defined in the EJB deployment descriptor or annotation.
    • If no roles have been assigned, or the method is specified 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 defined for the message queue destination or topic destination in the JBoss EAP configuration file.

    • 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.
      • 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 specified 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 specified, 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.

For more information see the Configuration Guide.

7.2. Role-Based Access Control for Management Interfaces

The management interfaces of JBoss EAP 7, the management CLI and the web-based management console, allow access to the JBoss EAP system configuration in order to manage all configurable aspects of JBoss EAP 7. Administrators can access general system aspects, such as network port configurations, and container configurations. In addition, configuration aspects for services offered by containers are managed as well.

The configuration of applications, such as the application access control, are addressed in the deployment descriptors shipped with the application. Therefore, application configuration is generally not accessible via the management interfaces.

The administrative interfaces can be bound to a specific network interface. This allows for the management interfaces to be restricted to an administration LAN in order to prevent untrusted users from accessing the management interfaces. In order for administrators to interact with administrative interfaces, they must log in. Administration accounts are maintained separately from other user accounts.

Each action on an object that an administrative user can perform is subject to a role-based access control mechanism. The actions are classified into:

  • Model operations, whose main function is to read/write from the model, although there will often be associated runtime services started/stopped as a consequence.
  • RPC operations, which invokes some runtime that affects runtime state only. This may either read runtime state or change it. The model is not affected.

A set of object-action capabilities are mapped to a management role. This mapping defines the allowed access for the management role. A set of pre-defined management roles is included with JBoss EAP PROD_VER and is available after installation. The pre-configured roles are detailed below.

Role-based Access Control Pre-configured Management Roles

Table 7.1. Role-based access control

RoleDescription

Monitor

The Monitor role has the fewest permissions and restricts the user to viewing the configuration and the current state. The monitor role does not have permission to modify the server configuration, 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 configuration. 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 configuration, or access sensitive data or operations.

Maintainer

The Maintainer role has access to view and modify the runtime state and all configurations 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 configure 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 configuration 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. These permissions include constraints, for example the read permissions for the Monitor role is constrained to non-sensitive actions and targets. Redefinition 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 permission, for example the target must be related to a particular host or server group.

All administrative operations are stored in configuration files (either domain.xml or standalone.xml depending on the startup mode). The administrative interfaces are an in-memory image of the data stored in the configuration file. Once the in-memory image is modified, the modified configuration file is stored.

The role-based access control mechanism can only be enforced if the administrator accesses the JBoss EAP PROD_VER system configuration using the management CLI or management console. If an administrator has shell access to the host, the underlying operating system may grant direct read or write access to the JBoss EAP system configuration files. Such access would imply that the role-based access control mechanism is not enforced. It is assumed that the host is located in a protected environment where direct access to the JBoss EAP system configuration files is not allowed.

7.3. Audit

JBoss EAP 7 can generate audit records for access control events. Attempts to access web resources, invocation of EJB methods, unauthorized message destinations, and regular web service related access control can all be logged. As the administrator you can select the level of events to audit.

The audit facility is based on the integrated log4j mechanism. log4j has three main components: loggers, appenders, and layouts. These three types of components work together to enable developers to log messages according to message type and level, and to control at run-time how these messages are formatted and where they are reported.

The audit information is recorded in text files which can be reviewed using tools from the underlying operating system, such as pagers or editors. Audit records can also be forwarded to a syslog server for additional audit controls.

User information, principal name, appears only in the first log that records the authentication request, and also in the ERROR log generated if the authentication is unsuccessful. Subsequent log events do not explicitly record the user executing the methods.

User information can be obtained by using the container and thread IDs that are recorded in each audit log and remain during the life of the user session.

7.4. Clustering

A cluster is a set of nodes. In a JBoss EAP 7 cluster, a node is a JBoss EAP 7 server instance. To build a cluster, several JBoss EAP 7 instances have to be grouped together, also known as a partition.

Clustering allows the execution of applications on several parallel nodes. Two cluster concepts are possible with JBoss EAP 7: a failover cluster, and a load-distribution cluster. In both cases, the server state is distributed across different servers, and if any server fails, the application is still accessible via other cluster nodes.

Cluster communication establishes data consistency between different cluster nodes. JGroups and Infinispan provide the underlying communication, node replication, and caching services for JBoss EAP 7 clusters. These services are configured as MBeans. There is a set of Infinispan and JGroups MBeans for each type of clustering applications (for example, the Stateful Session EJBs, the distributed entity EJBs, etc.).

Infinispan provides distributed cache and state replication services for the JBoss EAP 7 cluster. A JBoss EAP 7 cluster can have multiple Infinispan MBeans: one for HTTP session replication, one for stateful session beans, one for cached entity beans, and so on.

The following information is replicated as part of cluster communication:

  • Replication of the state of a node includes the replication of HTTP sessions, EJB 3.0 session beans, EJB 3.0 entity beans, as well as Hibernate persistence objects (distributed state replication service using Infinispan).
  • Replication of the state of a node covering the replication of HTTP sessions, and EJB 2.x session beans.
  • Replication of JBoss Messaging queues. Messages sent to a distributed queue or topic on one node are consumable on other nodes.

JBoss EAP 7 does not perform an automated replication of the JNDI state. When applications defining JNDI resources are replicated to different cluster nodes, they are newly deployed at the nodes. With this deployment, the JNDI resources are created similar to a regular deployment. System configuration changes that involve modifications of JNDI resources are replicated to the cluster nodes, and applied similarly to a local reconfiguration. The JNDI registry maintaining the JNDI mappings is managed consistently between the different cluster nodes. As JNDI does not maintain a state other than the JNDI registry, this is sufficient to ensure cluster-wide consistency of the JNDI service.

7.5. Identification and Authentication

Users are assigned unique user identifiers which are used as the basis for access control decisions and auditing.

JBoss EAP 7 authenticates the identity of the user before allowing the user to perform any further security-mediated actions.

JBoss EAP 7 internally maintains the identifier associated with the thread spawned for a user after a successful authentication.

JBoss EAP 7 provides different identification and authentication mechanisms for different request types:

  • HTTP and web services: HTTP-basic authentication, HTTP-digest authentication, form-based authentication, client certificate-based authentication.
  • EJB: Username and password-based authentication, client certificate-based authentication.
  • JMS: Username and password-based authentication.

7.6. Transaction Rollback

JBoss EAP 7 supports the aggregation of operations into transactions, which can be applied and rolled back consistently.

A transaction is a unit of work containing one or more operations involving one or more shared resources having atomicity, consistency, isolation and durability (ACID) properties - the four important properties of transactions.

  • 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 only part of a transaction is not allowed.
  • Consistency: When a transaction is completed, the system must be in a stable and consistent condition.
  • Isolation: Different 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 afterward.

The default transaction manager for JBoss EAP 7 is JBoss Transactions, a fast in-VM transaction manager implementation.

Traditionally, ACID transaction systems have shared the following characteristics:

  • Transactions are short lived
  • Resources (such as databases) are locked for the duration of the transaction
  • Participants have a high degree of trust with each other

The advent of the Internet and web services has given rise to distributed transactions between participants unknown to each other. JBoss Transactions adds native support for web services transactions by providing the components necessary to build interoperable, reliable, multi-party, web services-based applications with minimum effort.

The programming interfaces are based on the Java API for XML Transactions (JAXTX) and include protocol support for the WS-AtomicTransaction and WS-BusinessActivity specifications. JBoss is designed to support multiple coordination protocols.

JBoss EAP 7 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 services transactions component can be utilized, which uses SOAP/HTTP.