Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 16. Securing Your System
16.1. Security Assertion Markup Language (SAML) Link kopierenLink in die Zwischenablage kopiert!
16.2. Issuing a SAML Security Token Link kopierenLink in die Zwischenablage kopiert!
Procedure 16.1. Task
- Obtain the Login Module (LM) located in org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule
- Open the LM's configuration file.
- Enter the following code, inserting the names of the services you wish to use:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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. - Specify the picketlink-sts-client properties:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Note
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. - 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:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 Link kopierenLink in die Zwischenablage kopiert!
Procedure 16.2. Task
- Open the Login Module (LM) from org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule.
- Configure the properties file as shown in the example below:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Note
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.Note
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 http://www.jboss.org/community/wiki/STSLoginModules
16.4. PicketLink Link kopierenLink in die Zwischenablage kopiert!
16.5. Integration Between SAML and PicketLink Link kopierenLink in die Zwischenablage kopiert!
- The client must first obtain the SAML assertion from PicketLink STS by sending a WS-Trust request to the token service. This process usually involves authentication of the client.
- After obtaining the SAML assertion from the STS, the client includes the assertion in the security context of the EJB request before invoking an operation on the bean.
- Upon receiving the invocation, the EJB container extracts the assertion and validates it by sending a WS-Trust message to the STS. If the assertion is deemed valid by the STS (and the proof of possession token has been verified if needed), the client is authenticated.
- In JBoss, the SAML assertion validation process is handled by the SAML2STSLoginModule. It reads properties from a configurable file (specified by the configFile option) and establishes communication with the STS based on these properties.
- If the assertion is valid, a Principal is created using the assertion subject name. If the assertion contains roles, these roles are also extracted and associated with the caller's Subject.
16.6. Securing Your JBoss Enterprise SOA Platform Installation Link kopierenLink in die Zwischenablage kopiert!
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.
- through a gateway
- directly via the ServiceInvoker.
UsernameToken
or the BinarySecurityToken
from the SOAP header's security element.
16.7. Java Authentication and Authorization Service (JAAS) Link kopierenLink in die Zwischenablage kopiert!
16.8. JaasSecurityService Link kopierenLink in die Zwischenablage kopiert!
16.9. Secure Your System Link kopierenLink in die Zwischenablage kopiert!
Procedure 16.3. Task
vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml
.
- Scroll down to the section that contains properties name="security" and edit the settings to suit your system:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Save the file and exit.
- Open the log-in configuration file in your text editor:
vi SOA_ROOT/server/PROFILE/conf/login-config.xml
- 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.)
- Save the file and exit.
16.10. Create an Encrypted Password File Link kopierenLink in die Zwischenablage kopiert!
Procedure 16.4. Task
- Go to the
conf
directory:cd SOA_ROOT/jboss-as/server/PROFILE/conf
- Execute this command:
java -cp ../../../lib/jbosssx.jar org.jboss.security.plugins.FilePassword welcometojboss 13 testpass esb.password
An encrypted password file is created.
16.11. Encryption Options Link kopierenLink in die Zwischenablage kopiert!
Option | Description |
---|---|
Salt |
This is the "salt" used to encrypt the password file. (In the example above, it is the
welcometojboss string .)
|
Iteration |
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.
|
testpass |
This is the test password.
|
16.12. Clear-Text Password Link kopierenLink in die Zwischenablage kopiert!
16.13. Password Mask Link kopierenLink in die Zwischenablage kopiert!
16.14. Masking Passwords Link kopierenLink in die Zwischenablage kopiert!
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.
Important
16.15. Mask a Clear-Text Password Link kopierenLink in die Zwischenablage kopiert!
Important
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
- Generate a key pair using this command:
keytool -genkey -alias jboss -keyalg RSA -keysize 1024 -keystore password.keystore
and follow the prompts:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Note
You must specify the same password for the key store and key pair. - Run
chown
to change ownership to the JBoss Application Server process owner, andchmod 600 password.keystore
to make sure only the file's owner can read it.Note
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. - Navigate to the
jboss-as/bin
directory:cd SOA_ROOT/jboss-as/bin
- Run the password tool, using the command
./password_tool.sh
on Red Hat Enterprise Linux systems, (orpassword_tool.bat
on Microsoft Windows-based systems.) - Select
0: Encrypt Keystore Password
by pressing 0, then Enter. - Enter the key store password you specified above.
- Enter a random string of characters to aid with encryption strength. This is the salt.
- Enter a whole number for the iterator count to aid with encryption strength.
- Select
5: Exit
to exit.Note
The password tool will exit with the message:Keystore is null. Cannot store.
This is normal. - Use the
chown
command to change ownership of thepassword/jboss_keystore_pass.dat
file to the process owner, andchmod 600 jboss-keystore_pass.dat
to ensure that only that owner can read the file. - Navigate to the
jboss-as/bin
directory:cd SOA_ROOT/jboss-as/bin
- Run the password tool, using the command
./password_tool.sh
on Red Hat Enterprise Linux systems (orpassword_tool.bat
on Microsoft Windows systems). - Select
1: Specify KeyStore
by pressing 1 then Enter. - 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 beSOA_ROOT/jboss-as/bin/password.keystore
, unless you have changed the defaults.) - Enter the key alias. This should be "jboss" (unless you have performed an advanced installation and changed the defaults).
- Select
2: Create Password
by pressing 2, then Enter. You will be prompted for the security domain. Follow the prompts on screen.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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.
- Enter the password that you wish to mask.
- Repeat the password mask creation process to create masks for all passwords you wish to mask.
- Exit the program by choosing
5: Exit
- Navigate to the
password
directory:cd SOA_ROOT/jboss-as/bin/password
16.16. Replace a Clear Text Password with its Password Mask Link kopierenLink in die Zwischenablage kopiert!
Prerequisites
- 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> @org.jboss.security.integration.password.Password(securityDomain=MASK_NAME, methodName=setPROPERTY_NAME) </annotation>
<annotation> @org.jboss.security.integration.password.Password(securityDomain=MASK_NAME, methodName=setPROPERTY_NAME) </annotation>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow As a concrete example, the JBoss Messaging password is stored in the server profile'sdeploy/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"> CHANGE ME!! </property>
<property name="suckerPassword"> CHANGE ME!! </property>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <annotation> @org.jboss.security.integration.password.Password(securityDomain=messaging, methodName=setSuckerPassword) </annotation>
<annotation> @org.jboss.security.integration.password.Password(securityDomain=messaging, methodName=setSuckerPassword) </annotation>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.17. Change the Default Password Mask Settings Link kopierenLink in die Zwischenablage kopiert!
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
- Open the security configuration file in a text editor:
vi SOA_ROOT/jboss-as/server/PROFILE/deploy/security/security-jboss-beans.xml
. - Edit the key store location and key alias. Here are some example settings:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Save the file and exit.
16.18. Global Configuration File Security Settings Link kopierenLink in die Zwischenablage kopiert!
Property | Description | Required? |
---|---|---|
org.jboss.soa.esb.services.security.implementationClass |
This is the "concrete"SecurityService implementation that should be used. The default setting is
JaasSecurityService .
|
Yes
|
org.jboss.soa.esb.services.security.callbackHandler |
This is a default
CallbackHandler implementation, utilized when a JAAS-based SecurityService is employed. See “Customizing Security” for more information about the CallbackHandler property.
|
No
|
org.jboss.soa.esb.services.security.sealAlgorithm |
This is the algorithm to use when "sealing" the
SecurityContext .
|
No
|
org.jboss.soa.esb.services.security.sealKeySize |
This is the size of the secret/symmetric key used to encrypt/decrypt the
SecurityContext .
|
No
|
org.jboss.soa.esb.services.security.contextTimeout |
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.
|
No
|
org.jboss.soa.esb.services.security.contextPropagatorImplementationClass |
Use this to configure a global
SecurityContextPropagator . (For more details on the SecurityContextPropagator , please refer to the section on “Advanced Security Options”.)
|
No
|
org.jboss.soa.esb.services.security.publicKeystore |
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 .
|
No
|
org.jboss.soa.esb.services.security.publicKeystorePassword |
This is the password for the public keystore.
|
No
|
org.jboss.soa.esb.services.security.publicKeyAlias |
This is the alias to use for the public key.
|
No
|
org.jboss.soa.esb.services.security.publicKeyPassword |
This is the password for the alias if one was specified upon creation.
|
No
|
org.jboss.soa.esb.services.security.publicKeyPassword |
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.
|
No
|
16.19. Key Pair Link kopierenLink in die Zwischenablage kopiert!
16.20. Keystore Link kopierenLink in die Zwischenablage kopiert!
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 Link kopierenLink in die Zwischenablage kopiert!
16.22. Content Based Routing Using the JBoss Rules Engine Link kopierenLink in die Zwischenablage kopiert!
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).
Note
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. TheWireTap
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 http://www.eaipatterns.com/WireTap.html. - 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 http://www.eaipatterns.com/Filter.html.
16.23. Rule Base Link kopierenLink in die Zwischenablage kopiert!
16.24. Serialize Link kopierenLink in die Zwischenablage kopiert!
16.25. Deserialize Link kopierenLink in die Zwischenablage kopiert!
16.26. JBoss Rules and Security Link kopierenLink in die Zwischenablage kopiert!
Important
16.27. Enable Serialization on the Server Link kopierenLink in die Zwischenablage kopiert!
Procedure 16.8. Task
- Navigate to the SOA_ROOT directory:
cd SOA_ROOT
. - Run the
keytool
command and follow the prompts on screen:Copy to Clipboard Copied! Toggle word wrap Toggle overflow After answering all of the questions, a password-protected file namedMyDroolsPrivateKeyStore.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 thekeystoredir
.Important
The passwords above are examples only and should not be used in production. - Open the configuration file:
vi jboss-as/server/default/deploy/properties-service.xml
- Configure the JBoss Enterprise SOA Platform to use the JBoss Rules serialization feature by adding this snippet to
properties-service.xml
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Set the drools.serialization.sign property to "true":
drools.serialization.sign=true
drools.serialization.sign=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - drools.serialization.private.keyStoreURL=<RL> is the URL of the private keystore location.
- In the example above, replace
keystoredir
andMyDroolsKeyStore.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.
- Save the file and exit.
- Restart the server instance.
Warning
If the system properties were not configured properly, you will see this error when you try to build a rules package:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.28. Enable Serialization on the Client Link kopierenLink in die Zwischenablage kopiert!
Prerequisites
- Server serialization must already be enabled.
Procedure 16.9. Task
- 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
keytool -export -alias droolsKey -file droolsKey.crt -keystore
Copy to Clipboard Copied! Toggle word wrap Toggle overflow MyDroolsPrivateKeyStore.keystore Enter keystore password: Certificate stored in file <droolsKey.crtU>
MyDroolsPrivateKeyStore.keystore Enter keystore password: Certificate stored in file <droolsKey.crtU>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
keytool -import -alias droolsKey -file droolsKey.crt -keystore
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Open the server configuration file:
vi grep drools jboss-as/server/default/deploy/properties-service.xml
- 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
# Drools Client Properties for Security Serialization drools.serialization.public.keyStoreURL=file://$keystoredir/MyPublicDroolsKeyStore.keystore drools.serialization.public.keyStorePwd=drools
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Save the file and exit.
- Restart the JBoss Enterprise SOA Platform server.
- For Java client applications, set the system properties in your code like this:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Alternatively, open therun.sh
shell script (vi SOA_ROOT/jboss-as/bin/run.sh
) script and edit the JAVA_OPTS section:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace the values shown above with ones specific to your environment, and then restart the server instance.
16.29. Disable Serialization Signing Link kopierenLink in die Zwischenablage kopiert!
- Open the configuration file:
vi SOA_ROOT/jboss-as/server/PROFILE/deploy/properties-service.xml
. - Remove the drools.serialization.sign property's value.
- Save the file and exit.An alternative way to do this task is to open the
run.sh
shell script (vi SOA_ROOT/jboss-as/bin/run.sh
) and edit it as follows:JAVA_OPTS="-Ddrools.serialization.sign=false $JAVA_OPTS"
JAVA_OPTS="-Ddrools.serialization.sign=false $JAVA_OPTS"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Restart the server instance.
- 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" );
System.setProperty( KeyStoreHelper.PROP_SIGN, "false" );
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.30. Configure Security on a Per-Service Basis Link kopierenLink in die Zwischenablage kopiert!
- Open the global configuration file in a text editor:
vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jboss-esb.xml
. - Scroll down to the service you want to configure.
- Add a security element. This setting shows you how to do so:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Save the file and exit.
16.31. Per-Service Security Properties Link kopierenLink in die Zwischenablage kopiert!
Property | Description | Required? |
---|---|---|
moduleName |
This is a module that exists in the
SOA_ROOT/jboss-as/server/PROFILE/conf/login-config.xml file.
| No |
runAs |
This is the runAs role.
| No |
rolesAllowed |
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.
| No |
callbackHandler |
This is the
CallbackHandler that will override that which was defined in the jbossesb-properties.xml file.
| No |
property |
These are optional properties that, once defined, will be made available to the
CallbackHandler implementation.
| No |
16.32. Override Global Security Settings Link kopierenLink in die Zwischenablage kopiert!
Procedure 16.10. Task
- Open the global configuration file in a text editor:
vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml
. - Configure the setting in question. Here is an example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Save the file and exit.
16.33. Security Property Overrides Link kopierenLink in die Zwischenablage kopiert!
Property | Description | Required? |
---|---|---|
org.jboss.soa.esb.services.security.contextTimeout |
This property lets the service override the global security context time-out (milliseconds) that is specified in the
jbossesb-properties.xml file.
| No |
org.jboss.soa.esb.services.security.contextPropagatorImplementationClass |
This property lets the service to override the "global security context propagator" class implementation, that is specified in the
jbossesb-properties.xml file.
| No |
16.34. Security Context Link kopierenLink in die Zwischenablage kopiert!
16.35. Authentication Request Link kopierenLink in die Zwischenablage kopiert!
16.36. SecurityConfig Link kopierenLink in die Zwischenablage kopiert!
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 Link kopierenLink in die Zwischenablage kopiert!
Procedure 16.11. Task
- Execute this code:
byte[] encrypted = PublicCryptoUtil.INSTANCE.encrypt((Serializable) authRequest); message.getContext.setContext(SecurityService.AUTH_REQUEST, encrypted);
byte[] encrypted = PublicCryptoUtil.INSTANCE.encrypt((Serializable) authRequest); message.getContext.setContext(SecurityService.AUTH_REQUEST, encrypted);
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 Link kopierenLink in die Zwischenablage kopiert!
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 Link kopierenLink in die Zwischenablage kopiert!
Procedure 16.12. Task
- Open the global configuration file in a text editor:
vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml
. - Scroll down to the section that contains security.contextTimeout. Set the time-out value (in milliseconds).
- Save the file and exit.
16.40. Set a Time Limit for the Security Context on a Per-Service Basis Link kopierenLink in die Zwischenablage kopiert!
Procedure 16.13. Task
- Open the service's configuration file in a text editor:
vi jboss-esb.xml
. - Scroll down to the section that contains Security Context. Set the time-out value (in milliseconds).
- Save the file and exit.