Chapter 5. Configuration Requirements

The following sections describe modifications to be made to the server configuration to comply with CC requirements. When changes are made using the management console or management CLI, the existing configuration is automatically backed up. You can use those backups for reference or to revert to an earlier configuration if required. See the Configuration Guide for further details of this feature.

5.1. Network Configuration

5.1.1. Network Interfaces

The following network interfaces are defined and created so that trusted and untrusted network traffic is separated.

public
For communication to and from external, potentially untrusted parties.
cluster
For communication between cluster nodes. Cannot be accessed by untrusted parties. This must be enforced as part of network/firewall configuration.
internal
For communication between trusted servers or users (such as administrators) via the internal network. Cannot be accessible to untrusted parties or general users of the system.

5.1.2. Network Interface Configuration

To ensure compliance with Common Criteria requirements, apply the relevant network configurations.

Define and Configure Network Interfaces

  1. Create internal and cluster network interfaces. 

    [standalone@localhost:9990 /] /interface=cluster:add(inet-address=expression "${jboss.bind.address.cluster:127.0.0.1}")
[standalone@localhost:9990 /] /interface=internal:add(inet-address=expression "${jboss.bind.address.internal:127.0.0.1}")

  2. Bind each socket to the specified network interface.

    For each line in Network Bindings, use the following command to bind the socket to the specified network interface. 

    [standalone@localhost:9990 /] /socket-binding-group=standard-sockets/socket-binding=BINDING_NAME:write-attribute(name=interface,value=NETWORK_INTERFACE)
    Note

    Not all socket bindings are relevant to the available configuration by default. Only those that are part of the product configuration are applicable.

    For example, the following command binds management-http to the internal network interface: 

    [standalone@localhost:9990 /] /socket-binding-group=standard-sockets/socket-binding=management-http:write-attribute(name=interface,value=internal)

  3. Remove the unsecure network interface from the following configuration files: standalone-full.xml and standalone-full-ha.xml. 

    [standalone@localhost:9990 /] /interface=unsecure:remove

  4. Restart JBoss EAP.

    Restart JBoss EAP so that the network bindings take effect.

Table 5.1. Network Bindings

Binding NameNetwork InterfacePort Number

ajp

internal

8009

http

public

8080

https

public

8443

iiop

internal

3528

iiop-ssl

internal

3529

jgroups-mping

cluster

0 - multicast: 45700

jgroups-tcp

cluster

7600

jgroups-udp

cluster

55200 - multicast: 45688

management-http

internal

9990

management-https

internal

9993

messaging

internal

5445

messaging-throughput

internal

5455

modcluster

public/internal

0 - multicast: 23364

txn-recovery-environment

internal

4712

txn-status-manager

internal

4713

5.2. Security Configuration

The following configuration steps must be performed to ensure security compliance with Common Criteria requirements.

Enable Elytron Security Across the Server

Important

The legacy security subsystem is not compliant with Common Criteria. Disable the legacy security subsystem and enable the elytron subsystem.

There is a simple way to enable Elytron across the server. JBoss EAP 7.2 introduced an example configuration script that enables Elytron as the security provider. This script resides in the EAP_HOME/docs/examples directory in the server installation.

Note

The example configuration script includes references to the native interface, which is no longer supported. Remove the following lines from this script: 

/host=master/core-service=management/management-interface=native-interface:write-attribute(name=sasl-authentication-factory,value=management-sasl-authentication) /host=master/core-service=management/management-interface=native-interface:undefine-attribute(name=security-realm)

Execute the following command to enable Elytron security across the server. The server must be completely stopped before executing the command. 

$ EAP_HOME/bin/jboss-cli.sh --file=EAP_HOME/docs/examples/enable-elytron.cli

5.2.1. About Authorization

In JBoss EAP 7, a SecurityDomain references one or more SecurityRealms for loading identities. These identities are used for authentication. They also contain role decoder and mapper references to map the identity for authorization decisions.

Authorization is different from authentication, and usually happens after authentication.

Note

XACML is not permitted in the Common Criteria Certified configuration.

5.2.2. Java Security Manager

The Java Security Manager is a class that manages the external boundary of the Java Virtual Machine (JVM) sandbox, controlling how code executing within the JVM can interact with resources outside the JVM. When the Java Security Manager is activated, the Java API checks with the security manager for approval before executing a wide range of potentially unsafe operations. The Java Security Manager uses a security policy to determine whether a given action will be allowed or denied.

Important

JBoss EAP 7 defines Java Security Policies in two ways: the security-manager subsystem and through XML files in the individual deployments. The security-manager subsystem defines minimum and maximum permission for ALL deployments, while the XML files specify the permissions requested by the individual deployment. Before starting JBoss EAP with the Java Security Manager enabled, you need make sure all security policies are defined in the security-manager subsystem.

For more information on defining policies in the security-manager subsystem, refer the Java Security Manager section in the How to Configure Server Security for JBoss EAP.

Run JBoss EAP With the Java Security Manager

To run JBoss EAP with the Java Security Manager, you need to use the secmgr option during startup. There are two ways to do this:

  • Use the flag with the startup script To use the -secmgr flag with the startup script, include it when starting up your JBoss EAP instance:

    Example: Startup Script

    ./standalone.sh -secmgr

  • Using the Startup Configuration File

    Important

    The domain or standalone server must be completely stopped before you edit any configuration files.

    Note

    If you are using JBoss EAP in a managed domain, you must perform the following procedure on each physical host or instance in your domain.

    To enable the Java Security Manager using the startup configuration file, you need to edit either the standalone.conf or domain.conf file, depending if you are running a standalone instance or managed domain. If running in Windows, the standalone.conf.bat or domain.conf.bat files are used instead.

    Uncomment the SECMGR="true" line in the configuration file:

    Example: standalone.conf or domain.conf

    # Uncomment this to run with a security manager enabled
SECMGR="true"

    Example: standalone.conf.bat or domain.conf.bat

    rem # Uncomment this to run with a security manager enabled
set "SECMGR=true"

5.2.3. EJB Authorization Policy

Applications can implement custom authentication and authorization verification using a Java Authorization Contract for Containers (JACC) Authorization Module. In JBoss EAP 7, the JACC authorization module forms part of a JAAS security domain.

5.2.3.1. Enabling JACC Using the elytron Subsystem

Disable JACC in the Legacy Security Subsystem

By default, the application server uses the legacy security subsystem to configure the JACC policy provider and factory. The default configuration maps to implementations from PicketBox.

In order to use Elytron to manage JACC configuration, or any other policy you want to install to the application server, you must first disable JACC in the legacy security subsystem. For that, you can use the following management CLI command: 

/subsystem=security:write-attribute(name=initialize-jacc, value=false)

Failure to do so can result in the following error in the server log: MSC000004: Failure during stop of service org.wildfly.security.policy: java.lang.StackOverflowError.

Define a JACC Policy Provider

The elytron subsystem provides a built-in policy provider based on JACC specification. To create the policy provider you can execute the following management CLI command: 

/subsystem=elytron/policy=jacc:add(jacc-policy={})

reload

Enable JACC to a Web Deployment

Once a JACC policy provider is defined, you can enable JACC for web deployments by executing the following command: 

/subsystem=undertow/application-security-domain=other:write-attribute(name=enable-jacc,value=true)

The command above enables JACC for the "other" application-security-domain in the Undertow subsystem.

Note

The "other" application-security-domain gets added when running the script that enables Elytron across the server. See Security Configuration.

Important

If you have not run the script for enabling Elytron across the server, you must first run the following command: 

/subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain)

Enable JACC to an EJB Deployment

Once a JACC policy provider is defined, you can enable JACC for EJB deployments by executing the following command: 

/subsystem=ejb3/application-security-domain=other:write-attribute(name=enable-jacc,value=true)

The command above enables JACC for the "other" application-security-domain in the EJB subsystem.

Note

The "other" application-security-domain gets added when running the script that enables Elytron across the server. See Security Configuration.

Important

If you have not run the script for enabling Elytron across the server, you must first run the following command: 

/subsystem=ejb3/application-security-domain=other:add(security-domain=ApplicationDomain)

Creating a Custom Elytron Policy Provider

A custom policy provider is used when you need a custom java.security.Policy, like when you want to integrate with some external authorization service in order to check permissions. To create a custom policy provider, you will need to implement the java.security.Policy, create and plug in a custom module with the implementation and use the implementation from the module in the elytron subsystem. 

/subsystem=elytron/policy=policy-provider-a:add(custom-policy={class-name=MyPolicyProviderA, module=x.y.z})

For more information, see the Policy Provider Properties in the Development Guide.

Note

In most cases, you can use the JACC policy provider as it is expected to be part of any Java EE compliant application server.

5.3. Elytron Subsystem

The elytron subsystem is new in JBoss EAP 7.2. It is based on the WildFly Elytron project, which is a security framework used to unify security across the entire application server. The elytron subsystem enables a single point of configuration for securing both applications and the management interfaces. WildFly Elytron also provides a set of APIs and SPIs for providing custom implementations of functionality and integrating with the elytron subsystem.

Note

The elytron subsystem is responsible for the security of a CC compliant system. Legacy security subsystem and legacy security realms are not supported.

Note

Vaults are not supported in the CC compliant system. Credential store is the recommended solution instead.

You can find more background information on different Elytron components in the Security Architecture guide.

5.3.1. Adding and Removing the Elytron Subsystem

Note

If you are starting with JBoss EAP 7.2, the elytron subsystem is already present and no further configuration is required.

This is required only when you are using an older JBoss EAP installation.

To add the elytron extension required for the elytron subsystem: 

/extension=org.wildfly.extension.elytron:add()

To add the elytron subsystem in JBoss EAP: 

/subsystem=elytron:add

reload

To remove the elytron subsystem in JBoss EAP: 

/subsystem=elytron:remove

reload
Important

Other subsystems within JBoss EAP may have dependencies on the elytron subsystem. If these dependencies are not resolved before removing it, you will see errors when starting JBoss EAP.

5.4. Database Configuration

Note

For better startup server behavior, the preferred installation method for JDBC drivers is to install them as a core module.

Security Permissions for JDBC Drivers

  1. Security Permissions for JDBC Drivers in the Deployment

    In JBoss EAP 7, you can add a META-INF/permissions.xml to your deployment, which is part of JSR 342 and is a part of the Java EE specification. This file allows you to specify the permissions needed by the deployment.

    All permissions required by the deployment can be found in the documentation for the respective drivers.

  2. Security Permissions for JDBC Drivers in Modules

    For all JDBC drivers installed as modules, no extra settings are required for their security manager permissions.

For more information, see the Java Security Manager section in the How to Configure Server Security guide.

5.5. Guidance on Configuring Java Security Permissions

The system administrator for the operation of the certified system is expected to configure the security permissions for all enterprise applications that are deployed on the certified system, when the certified system runs in the security manager enabled mode.

Warning

In addition to the General Restrictions, the following permissions must not be granted to any application in order to maintain a certified configuration:

  • File permissions, except to files that are dedicated to the application
  • Network permissions
  • Permissions to load native code

For more information, refer the Define a Java Security Policy section in the How to Configure Server Security guide.