Red Hat Training

A Red Hat training course is available for JBoss Enterprise SOA Platform

Chapter 16. Securing Your System

16.1. Security Assertion Markup Language (SAML)

Security Assertion Markup Language (SAML) is a framework compiled in XML. It is used to sercurely pass information between services. It is most commonly used for authentication and identification. With SAML, users can login once and have their identity verified by SAML, thus negating the need to re-enter their credentials repeatedly.
The JBoss ESB uses the SAML provided by PicketLink Project via JAAS Login Modules. It provides users with the ability to assign and validate SAML security tokens.

16.2. Issuing a SAML Security Token

Procedure 16.1. Task

  1. Obtain the Login Module (LM) located in org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule
  2. Open the LM's configuration file.
  3. Enter the following code, inserting the names of the services you wish to use:
    <application-policy name="saml-issue-token">
             <login-module code="org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule" flag="required">
                 <module-option name="configFile"></module-option>
                 <module-option name="endpointURI">http://security_saml/goodbyeworld</module-option>
             <login-module code="org.picketlink.identity.federation.core.wstrust.auth.STSValidatingLoginModule" flag="required">
                 <module-option name="configFile"></module-option>
    This configuration uses a stacked LM. The security token from the first LM is later used by the second LM which will validate the security token. Having two separate LMs for this can be useful as there can be situations where you only need to validate a security token.
  4. Specify the picketlink-sts-client properties:


    The username and password in this file are only used by the STSValidatingLoginModule. The username and password may also be stacked or provided by a callback.
  5. To use this LM in JBossESB you need to update your server's login-config.xml with the above application-policy. You must also point the ESB service to where you want this LM to be used.
    For example, this is how you could configure it in jboss-esb.xml:
    <service category="SamlSecurityQuickstart" name="issueTokenService" invmScope="GLOBAL"
        description="This service demonstrates how a service can be configured to issue and validate a security token">
        <security moduleName="saml-issue-token" callbackHandler="">
            <!-- disable the security context timeout so that our security context is re-evaluated -->
            <property name="" value="0"/>
    The callbackHandler that is is specified is specific to the ESB. This is because it requires access to the authentication request in the ESB for retreiving the username and password of the user for whom a security token should be issued.

16.3. Validating a SAML Security Token

Procedure 16.2. Task

  1. Open the Login Module (LM) from org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule.
  2. Configure the properties file as shown in the example below:
            <application-policy name="saml-validate-token">
            <login-module code="org.picketlink.identity.federation.core.wstrust.auth.STSValidatingLoginModule" flag="required">
                <module-option name="configFile"></module-option>
    And in jboss-esb.xml:
    <service category="SamlSecurityQuickstart" name="securedSamlService" invmScope="GLOBAL"
        description="This service demonstrates that an ESB service can be configured to only validate a security token.">
        <security moduleName="saml-validate-token" callbackHandler="">
            <!-- disable the security context timeout so that our security context is re-evaluated -->
            <property name="" value="0"/>


    The callbackHandler that is specified is specific to the ESB. This is because it requires access to the authentication request in the ESB for retreiving the SAML Token which is to be validated.


    An example of SAML support in JBossESB can be found in the security_saml quickstart. More information about the Login Modules provied by PicketLink can be found at

16.6. Securing Your JBoss Enterprise SOA Platform Installation


The JBoss Enterprise SOA Platform can be made secure, in the sense that you can configure the product so that services will only be executed if caller authentication succeeds and said caller possesses the correct permissions. The default security implementation is based on JAAS.

There are two ways in which to invoke a service:
  1. through a gateway
  2. directly via the ServiceInvoker.
When you use the gateway option, it is made responsible for obtaining the security information needed to authenticate the caller. It does this by extracting the needed information from the transport. Once it has done so, it creates an authentication request that is encrypted and passed to the Enterprise Service Bus.
If you use the ServiceInvoker instead, it becomes the client application's responsibility to make the authentication request prior to invoking the service. This entails extracting either the UsernameToken or the BinarySecurityToken from the SOAP header's security element.

16.7. Java Authentication and Authorization Service (JAAS)

The JAAS 1.0 API consists of a set of Java packages designed for user authentication and authorization. The API implements a Java version of the standard Pluggable Authentication Modules (PAM) framework and extends the Java 2 Platform access control architecture to support user-based authorization.
JAAS was first released as an extension package for JDK 1.3 and is bundled with JDK 1.6.

16.8. JaasSecurityService

JaasSecurityService is the default implementation of JAAS used in the JBoss Enterprise SOA Platform.

16.9. Secure Your System

Procedure 16.3. Task

Open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml.
  1. Scroll down to the section that contains properties name="security" and edit the settings to suit your system:
    <properties name="security"> 
    <property name=""
    <property name="" 
    <property name="" 
    <property name="" 
    <property name="" 
    <property name= 
    <property name="" 
    <property name="" 
    <property name="" 
    <property name="" 
    <property name="" 
  2. Save the file and exit.
  3. Open the log-in configuration file in your text editor: vi SOA_ROOT/server/PROFILE/conf/login-config.xml
  4. Configure the JAAS log-in modules by editing the settings in this file. (You can use either a pre-configured option or create your own custom solution.)
  5. Save the file and exit.

16.10. Create an Encrypted Password File

Procedure 16.4. Task

  1. Go to the conf directory: cd SOA_ROOT/jboss-as/server/PROFILE/conf
  2. Execute this command: java -cp ../../../lib/jbosssx.jar welcometojboss 13 testpass esb.password

An encrypted password file is created.

16.11. Encryption Options

Table 16.1. Encryption Options

Option Description
This is the "salt" used to encrypt the password file. (In the example above, it is the welcometojboss string .)
This is the number of iterations. (In the example above, it is the number 13.)
Password File Name
This is the name of the file where the encrypted password will be saved. In the example above, it is the esb.password string.
This is the test password.

16.12. Clear-Text Password

A clear-text password is the plain text version of a password. It has either not been encrypted or has just been decrypted. Clear text passwords are unsecure.

16.13. Password Mask

A password mask is a template which determines what characters are allowed to be used in a password. For example, some password masks dictate that a password can only be alphanumeric while others allow special characters like ! and $ signs. Passwords which contain special characters are generally viewed as being more secure.

16.14. Masking Passwords


Passwords are secret authentication tokens that are used to limit access to resources to authorized parties only. For a JBoss services to access password-protected resources, the password must obviously be made available to it.

This can be done by means of command line arguments passed to the JBoss Enterprise SOA Platform on launch, however this is not practical in a production environment. Instead, passwords are normally made available to JBoss services through their inclusion in configuration files.
All JBoss Enterprise SOA Platform configuration files should be stored on secure file systems, and be made readable by the process owner only.
For an added level of security, you can also mask the password in the configuration file. This section will tell you how to do so.


There is no such thing as impenetrable security. Masking passwords is no exception - it is not impenetrable, but it does defeat casual inspection of configuration files, and increases the amount of effort that will be required to extract the password.

16.15. Mask a Clear-Text Password


You should only perform this key store password encryption procedure once. If you make a mistake entering the keystore password, or you change the key store at a later date, you should delete the jboss-keystore_pass.dat file and repeat the procedure. Be aware that if you change the key store any masked passwords that were previously generated will no longer function.

Procedure 16.5. Task

  1. Generate a key pair using this command: keytool -genkey -alias jboss -keyalg RSA -keysize 1024 -keystore password.keystore and follow the prompts:
            keytool -genkey -alias jboss -keyalg RSA -keysize 1024 -keystore password.keystore
    Enter keystore password:  
    Re-enter new password: 
    What is your first and last name?
      [Unknown]:  Bob Bobson
    What is the name of your organizational unit?
      [Unknown]:  Corporate_IT
    What is the name of your organization?
      [Unknown]:  XYZ
    What is the name of your City or Locality?
      [Unknown]:  BRISBANE
    What is the name of your State or Province?
      [Unknown]:  QLD
    What is the two-letter country code for this unit?
      [Unknown]:  AU
    Is CN=Bob Bobson, OU=Corporate_IT, O=XYZ, L=BRISBANE, ST=QLD, C=AU correct?
      [no]:  yes
    Enter key password for jboss
    	(RETURN if same as keystore password):


    You must specify the same password for the key store and key pair.
  2. Run chown to change ownership to the JBoss Application Server process owner, and chmod 600 password.keystore to make sure only the file's owner can read it.


    The process owner should not have console log-in access. In that case you will be performing these operations as another user. Creating masked passwords requires read access to the key store, so you may wish to complete configuration of masked passwords before restricting the key store file permissions.
  3. Navigate to the jboss-as/bin directory: cd SOA_ROOT/jboss-as/bin
  4. Run the password tool, using the command ./ on Red Hat Enterprise Linux systems, (or password_tool.bat on Microsoft Windows-based systems.)
  5. Select 0: Encrypt Keystore Password by pressing 0, then Enter.
  6. Enter the key store password you specified above.
  7. Enter a random string of characters to aid with encryption strength. This is the salt.
  8. Enter a whole number for the iterator count to aid with encryption strength.
  9. Select 5: Exit to exit.


    The password tool will exit with the message: Keystore is null. Cannot store. This is normal.
  10. Use the chown command to change ownership of the password/jboss_keystore_pass.dat file to the process owner, and chmod 600 jboss-keystore_pass.dat to ensure that only that owner can read the file.
  11. Navigate to the jboss-as/bin directory: cd SOA_ROOT/jboss-as/bin
  12. Run the password tool, using the command ./ on Red Hat Enterprise Linux systems (or password_tool.bat on Microsoft Windows systems).
  13. Select 1: Specify KeyStore by pressing 1 then Enter.
  14. Enter the path to the key store you created above. (You can specify an absolute path, or the path relative to SOA_ROOT/jboss-as/bin. This should be SOA_ROOT/jboss-as/bin/password.keystore, unless you have changed the defaults.)
  15. Enter the key alias. This should be "jboss" (unless you have performed an advanced installation and changed the defaults).
  16. Select 2: Create Password by pressing 2, then Enter. You will be prompted for the security domain. Follow the prompts on screen.
    ****  JBoss Password Tool********
    Error while trying to load data:Encrypted password file not located
    Maybe it does not exist and need to be created.
    0: Encrypt Keystore Password 1:Specify KeyStore 2:Create Password  3: Remove a domain 4:Enquire Domain 5:Exit
    Enter Keystore location including the file name
    Enter Keystore alias
    0: Encrypt Keystore Password 1:Specify KeyStore 2:Create Password  3: Remove a domain 4:Enquire Domain 5:Exit
    Enter security domain:
    Enter passwd:
    Password created for domain:default
    0: Encrypt Keystore Password 1:Specify KeyStore 2:Create Password  3: Remove a domain 4:Enquire Domain 5:Exit
  17. Enter a name for the password mask. This is an arbitrary unique name that you will use to identify the password mask in configuration files.
  18. Enter the password that you wish to mask.
  19. Repeat the password mask creation process to create masks for all passwords you wish to mask.
  20. Exit the program by choosing 5: Exit
  21. Navigate to the password directory: cd SOA_ROOT/jboss-as/bin/password

16.16. Replace a Clear Text Password with its Password Mask


  • Pre-existing password masks

Procedure 16.6. Task

  • Launch a text editor and replace each occurrence of a clear text password in the configuration files with an annotation referencing its mask.
    This is the general form of the annotation:
    <annotation>, methodName=setPROPERTY_NAME)
    As a concrete example, the JBoss Messaging password is stored in the server profile's deploy/messaging/messaging-jboss-beans.xml file. If you create a password mask named "messaging", then the before and after snippet of the configuration file will looks like this:
    <property name="suckerPassword">

16.17. Change the Default Password Mask Settings

By default the server profiles are configured to use the keystore SOA_ROOT/jboss-as/bin/password/password.keystore, and the key alias "jboss". If you store the key pair used for password masking elsewhere, or under a different alias, you will need to update the server profiles with the new location or key alias.

Procedure 16.7. Task

  1. Open the security configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/security/security-jboss-beans.xml.
  2. Edit the key store location and key alias. Here are some example settings:
    <!-- Password Mask Management Bean-->
       <bean name="JBossSecurityPasswordMaskManagement"
             class="" >
             <property name="keyStoreLocation">password/password.keystore</property>
             <property name="keyStoreAlias">jboss</property>
             <property name="passwordEncryptedFileName">password/jboss_password_enc.dat</property>
             <property name="keyStorePasswordEncryptedFileName">password/jboss_keystore_pass.dat</property>
  3. Save the file and exit.

16.18. Global Configuration File Security Settings

Table 16.2. jbossesb-properties.xml Security Settings

Property Description Required?
This is the "concrete"SecurityService implementation that should be used. The default setting is JaasSecurityService.
This is a default CallbackHandler implementation, utilized when a JAAS-based SecurityService is employed. See “Customizing Security” for more information about the CallbackHandler property.
This is the algorithm to use when "sealing" the SecurityContext.
This is the size of the secret/symmetric key used to encrypt/decrypt the SecurityContext.
This is the amount of time (in milliseconds) for which a security context is valid. A global setting, this may be over-ridden on a per-service basis. To do so, specify the property of the same name that exists on the security element in the jboss-esb.xml file.
Use this to configure a global SecurityContextPropagator. (For more details on the SecurityContextPropagator, please refer to the section on “Advanced Security Options”.)
This is the Keystore which holds the keys used to encrypt and decrypt that data which is external to the Enterprise Service Bus. The Keystore is used to encrypt the AuthenticationRequest.
This is the password for the public keystore.
This is the alias to use for the public key.
This is the password for the alias if one was specified upon creation.
This is a cipher transformation. It is in this format: algorithm/mode/padding. If this is not specified, the "keys" algorithm will be used by default.

16.19. Key Pair

A key pair is a set of security tools consisting of a public key and a private key. The public key is used for encryption and the private key is used for decryption.

16.20. Keystore

A keystore is a security mechanism. It contains a number of security certificates and their assigned "keys". It is used when client authentication is required.
The JBoss Enterprise SOA Platform ships with an example key-store, found in SOA_ROOT/jboss-as/samples/quickstarts/security_cert/keystore. Do not use this in a production environment. It is provided as an example only.

16.21. JBoss Rules

JBoss Rules is the name of the business rule engine provided as part of the JBoss Enterprise SOA Platform product.

16.22. Content Based Routing Using the JBoss Rules Engine

JBoss Rules is the rule provider "engine" for the content-based router. The Enterprise Service Bus integrates with this engine through three different routing action classes, these being:
  • a routing rule set, written in the JBoss Rules engine's DRL language (alternatively, you can use the DSL language if you prefer it);
  • the message content. This is the data that goes into the JBoss Rules engine (it comes in either XML format or as objects embedded in the message);
  • the destination (which is derived from the resultant information coming out of the engine).


When a message is sent to the content-based router, a rule-set will evaluate its content and return a set of service destinations.
  • org.jboss.soa.esb.actions.ContentBasedRouter: This action class implements the content-based routing pattern. It routes a message to one or more destination services, based on the message content and the rule set against which it is evaluating that content. The content-based router throws an exception when no destinations are matched for a given rule set or message combination. This action will terminate any further pipeline processing, so always position it last in your pipeline.
  • org.jboss.soa.esb.actions.ContentBasedWiretap: This implements the WireTap pattern. The WireTap is an enterprise integration pattern that sends a copy of the message to a control channel. The WireTap is identical in functionality to the standard content-based router, however it does not terminate the pipeline. It is this latter characteristic which makes it suitable to be used as a wire-tap, hence its name. For more information, see
  • org.jboss.soa.esb.actions.MessageFilter: This implements the message filter pattern. The message filter pattern is used in cases where messages can simply be dropped if certain content requirements are not met. In other words, it functions identically to the content-based router except that it does not throw an exception if the rule set does not match any destinations, it simply filters the message out. For more information, see

16.23. Rule Base

Rule bases are collections of rules. They are used in processing events. The rules help determine how information is stored and processed, which actions are allowed and what action to take when a message is being sent.

16.24. Serialize

To serialize an object is to convert it to a data object.

16.25. Deserialize

To deserialize a file is to transform it back into an object. It is the opposite of serialization.

16.26. JBoss Rules and Security

By default, the JBoss Rules component does not deserialize rules packages or unsigned rule bases.


You must activate this serialization security feature in order for your configuration to be supported by Red Hat. You need to configure system properties for both the application that serializes the packages and its rule bases (hereafter referred to as the server), as well as the application that deserializes the packages its rule bases (hereafter referred to as the client).

16.27. Enable Serialization on the Server

Procedure 16.8. Task

  1. Navigate to the SOA_ROOT directory: cd SOA_ROOT.
  2. Run the keytool command and follow the prompts on screen:
    keytool -genkey -alias droolsKey -keyalg RSA -keystore MyDroolsPrivateKeyStore.keystore
    Enter keystore password:  
    Re-enter new password: 
    What is your first and last name?
      [Unknown]:  Test User
    What is the name of your organizational unit?
      [Unknown]:  HR
    What is the name of your organization?
      [Unknown]:  Test Org
    What is the name of your City or Locality?
      [Unknown]:  Brisbane
    What is the name of your State or Province?
      [Unknown]:  QLD
    What is the two-letter country code for this unit?
      [Unknown]:  AU
    Is CN=Test User, OU=HR, O=Test Org, L=Brisbane, ST=QLD, C=AU correct?
      [no]:  yes
    Enter key password for droolsKey
         (RETURN if same as keystore password):  
    Re-enter new password:
    After answering all of the questions, a password-protected file named MyDroolsPrivateKeyStore.keystore is created. This keystore file has a private key called droolsKey with the password "drools". Store this file in a safe location in your environment, which will hereafter be referred to as the keystoredir.


    The passwords above are examples only and should not be used in production.
  3. Open the configuration file: vi jboss-as/server/default/deploy/properties-service.xml
  4. Configure the JBoss Enterprise SOA Platform to use the JBoss Rules serialization feature by adding this snippet to properties-service.xml:
    <mbean code=""  name="jboss:type=Service,name=SystemProperties">
        <attribute name="Properties">
          # Drools Security Serialization specific properties
  5. Set the drools.serialization.sign property to "true":
    • drools.serialization.private.keyStoreURL=<RL> is the URL of the private keystore location.
    • In the example above, replace keystoredir and MyDroolsKeyStore.keystore with your keystore directory and the name of the keystore you created with the keytool
    • drools.serialization.private.keyStorePwd=<password> is the password to access the private keystore.
    • drools.serialization.private.keyAlias=<key> is the key alias (identifier) of the private key.
    • drools.serialization.private.keyPwd=<password> is the private key password.
  6. Save the file and exit.
  7. Restart the server instance.


    If the system properties were not configured properly, you will see this error when you try to build a rules package:
    An error occurred building the package.
    signing object store: Key store with private key not configured. Please
    configure it properly before using signed serialization

16.28. Enable Serialization on the Client


  • Server serialization must already be enabled.

Procedure 16.9. Task

  1. Create a public key certificate from the private keystore. (You can access the keytool by running keytool -genkey -alias droolsKey -keyalg RSA -keystore.):
    keytool -export -alias droolsKey -file droolsKey.crt -keystore
    Enter keystore password:  
    Certificate stored in file <droolsKey.crtU>
  2. Import the public key certificate into a public keystore. (This is where it will be used by your client applications):
    keytool -import -alias droolsKey -file droolsKey.crt -keystore
    Enter keystore password:  
    Re-enter new password: 
    Owner: CN=Test User, OU=Dev, O=XYZ Corporation, L=Brisbane, ST=QLD, C=AU
    Issuer: CN=Test User, OU=Dev, O=XYZ Corporation, L=Brisbane, ST=QLD, C=AU
    Serial number: 4ca0021b
    Valid from: Sun Sep 26 22:31:55 EDT 2010 until: Sat Dec 25 21:31:55 EST 2010
    Certificate fingerprints:
         MD5:  31:1D:1B:98:59:CC:0E:3C:3F:57:01:C2:FE:F2:6D:C9
         SHA1: 4C:26:52:CA:0A:92:CC:7A:86:04:50:53:80:94:2A:4F:82:6F:53:AD
         Signature algorithm name: SHA1withRSA
         Version: 3
    Trust this certificate? [no]:  yes
    Certificate was added to keystore
  3. Open the server configuration file: vi grep drools jboss-as/server/default/deploy/properties-service.xml
  4. Replace keystoredir and MyPublicDroolsKeyStore.keystore with your keystore directory, and the name of the public keystore you created previously:
    # Drools Client Properties for Security Serialization
  5. Save the file and exit.
  6. Restart the JBoss Enterprise SOA Platform server.
  7. For Java client applications, set the system properties in your code like this:
    // Set the client properties to deserialize the signed packages
    URL clientKeyStoreURL = getClass().getResource( "MyPublicDroolsKeyStore.keystore" );
    System.setProperty( KeyStoreHelper.PROP_SIGN,
                                "true" );
    System.setProperty( KeyStoreHelper.PROP_PUB_KS_URL,
                                clientKeyStoreURL.toExternalForm() );
    System.setProperty( KeyStoreHelper.PROP_PUB_KS_PWD,
                                "drools" );
    Alternatively, open the shell script (vi SOA_ROOT/jboss-as/bin/ script and edit the JAVA_OPTS section:
    # Serialization Security Settings
    JAVA_OPTS="-Ddrools.serialization.sign=true $JAVA_OPTS"
    JAVA_OPTS="-Ddrools.serialization.private.keyStoreURL=file://$keystoredir/MyDroolsKeyStore.keystore $JAVA_OPTS"
    JAVA_OPTS="-Ddrools.serialization.private.keyStorePwd=drools $JAVA_OPTS"
    JAVA_OPTS="-Ddrools.serialization.private.keyAlias=droolsKey $JAVA_OPTS"
    JAVA_OPTS="-Ddrools.serialization.private.keyPwd=drools $JAVA_OPTS"
    JAVA_OPTS="-Ddrools.serialization.public.keyStoreURL=file://$keystoredir/MyPublicDroolsKeyStore.keystore $JAVA_OPTS"
    JAVA_OPTS="-Ddrools.serialization.public.keyStorePwd=drools $JAVA_OPTS"
    Replace the values shown above with ones specific to your environment, and then restart the server instance.

16.29. Disable Serialization Signing

  1. Open the configuration file: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/properties-service.xml.
  2. Remove the drools.serialization.sign property's value.
  3. Save the file and exit.
    An alternative way to do this task is to open the shell script (vi SOA_ROOT/jboss-as/bin/ and edit it as follows:
    JAVA_OPTS="-Ddrools.serialization.sign=false $JAVA_OPTS"
  4. Restart the server instance.
  5. To turn signing off for Java client applications, remove the drools.serialization.sign property or add the following snippet to each application's code:
    System.setProperty( KeyStoreHelper.PROP_SIGN, "false" );

16.30. Configure Security on a Per-Service Basis

  1. Open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jboss-esb.xml.
  2. Scroll down to the service you want to configure.
  3. Add a security element. This setting shows you how to do so:
    <service category="Security" name="SimpleListenerSecured"> 
       <security moduleName="messaging" runAs="adminRole"
        rolesAllowed="adminRole, normalUsers"
    	    <property name="property1" value="value1"/> 
    	    <property name="property2" value="value2"/> 
  4. Save the file and exit.

16.31. Per-Service Security Properties

Table 16.3. Security Properties

Property Description Required?
This is a module that exists in the SOA_ROOT/jboss-as/server/PROFILE/conf/login-config.xml file.
This is the runAs role.
This is an comma-separated list of those roles that have been granted the ability to execute the service. This is used as a check that is performed after a caller has been authenticated, in order to verify that they are indeed belonging to one of the roles specified. The roles will have been assigned after a successful authentication by the underlying security mechanism.
This is the CallbackHandler that will override that which was defined in the jbossesb-properties.xml file.
These are optional properties that, once defined, will be made available to the CallbackHandler implementation.

16.32. Override Global Security Settings

Procedure 16.10. Task

  1. Open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml.
  2. Configure the setting in question. Here is an example:
    <security moduleName="messaging" 
      runAs="adminRole" rolesAllowed="adminRole">
    <property name=
        value="" /> 
  3. Save the file and exit.

16.33. Security Property Overrides

Table 16.4. Security Property Overrides:

Property Description Required?
This property lets the service override the global security context time-out (milliseconds) that is specified in the jbossesb-properties.xml file.
This property lets the service to override the "global security context propagator" class implementation, that is specified in the jbossesb-properties.xml file.

16.34. Security Context

The SecurityContext is an object which is created after a security certificate is confirmed. After creation, it will be configured so that you do not have to re-authenticate the certificate every time you perform an action related to it. If the ESB detects that a message has a SecurityContext, it will check that it is still valid and, if so, it does not try to re-authenticate it. (Note that the SecurityContext is only valid for a single Enterprise Service Bus node. If the message is routed to a different ESB node, it will have to be re-authenticated.)

16.35. Authentication Request

An AuthenticationRequest carries the security information needed for authentication between either a gateway and a service or between two services. You must set an instance of this class on the message object prior to the authenticating service being called. The class must contain the principle and the credentials needed to authenticate a caller. This class is made available to the Callback Handler.

16.36. SecurityConfig

The SecurityConfig class grants access to the security configuration specified in the jboss-esb.xml file. This class is made available to the Callback Handler.

16.37. Add an Authentication Class to a Message Object

Procedure 16.11. Task

  • Execute this code:
    byte[] encrypted = PublicCryptoUtil.INSTANCE.encrypt((Serializable)
    message.getContext.setContext(SecurityService.AUTH_REQUEST, encrypted);

The authentication context is encrypted and then set within the message context. (It is later decrypted by the Enterprise Service Bus so that it can authenticate the request.)

16.38. security_basic Quick Start

The SOA_ROOT/jboss-as/samples/quickstarts/security_basic quick start demonstrates how to prepare the security on a message before you use the SecurityInvoker. The quick start also demonstrates how to configure the jbossesb-properties.xml global configuration file for use by client services.

16.39. Set a Time Limit for the Security Context Globally

Procedure 16.12. Task

  1. Open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml.
  2. Scroll down to the section that contains security.contextTimeout. Set the time-out value (in milliseconds).
  3. Save the file and exit.

16.40. Set a Time Limit for the Security Context on a Per-Service Basis

Procedure 16.13. Task

  1. Open the service's configuration file in a text editor: vi jboss-esb.xml.
  2. Scroll down to the section that contains Security Context. Set the time-out value (in milliseconds).
  3. Save the file and exit.