Security Guide
Use this guide to find out more about security for Red Hat JBoss Fuse Service Works.
Abstract
Chapter 1. SwitchYard Security
- Specifying a list of security policies that are required for that service.
- Configuring application-level security processing details for the services within a domain.
- Configuring system-level security processing details.
- Storing sensitive information, such as passwords, in the JBoss AS password vault.
See Also:
1.1. About SwitchYard Security
- Specify a list of security policies that are required for that service in the SwitchYard application descriptor (
switchyard.xml
). Edit theswitchyard.xml
file using the SwitchYard editor plug-in and specify the security policy by using the requires attribute of a component service definition as shown below:<service name="WorkService" requires="authorization clientAuthentication confidentiality">
- You can configure the security processing details for the services within a domain in the following ways:
- Select the Service for a component and view the Properties View in the SwitchYard editor.
- Hover over the Service for a component. A list of tools including theappears. It contains the security information.
- Ensure Authorization, Client Authentication and Confidentiality are checked.
1.2. Configuring Security for SwitchYard
META-INF/switchyard.xml
file.
<sy:switchyard> <sca:composite ...> <component ...> ... <service ... sy:security="security-name"> ... </service> <reference ... sy:security="default"> ... </reference> </component> <sca:composite> <domain> <securities> <security callbackHandler="callback-handler-class-name" name="security-name" rolesAllowed="users, administrators" runAs="leaders" securityDomain="jaas-domain-name"> <properties> <property name="property-name" value="property-value"/> </properties> </security> </securities> </domain> </sy:switchyard>
1.3. SwitchYard Security Configuration
META-INF/switchyard.xml
:
<switchyard> <domain> <security callbackHandler="callback-handler-class-name" moduleName="jaas-domain-name" rolesAllowed="users, administrators" runAs="leaders"> <properties> <property name="property-name" value="property-value"/> </properties> </security> </domain> </switchyard>
- The <security> element
- This is an optional element. If not specified, the callbackHandler and moduleName attributes described below will fallback to their default values.
- The callbackHandler attribute
- This is an optional attribute. If not specified, a default value of
org.switchyard.security.callback.NamePasswordCallbackHandler
will be used. - The moduleName attribute
- This is an optional attribute. If not specified, a default value of other will be used. The value maps to a JAAS security domain name.
- The rolesAllowed attribute
- This is an optional attribute. If specified, and if a Service has an authorization security policy requirement, the authenticated user must be in one of the roles listed. The value is a comma-separated list of roles (whitespace gets trimmed).
- The runAs attribute
- This is an optional attribute. If specified, the value of this attribute will be added as a role to the authenticated user.
- The <properties> and <property> elements
- A <security> element can optionally specify a <properties> element. This can be adjusted to specify zero to many (0..*) <property> elements. Each <property> element requires a name and a value attribute.
Note
1.4. Using Security Elements and Attributes
- The <component><service> and <component><reference> security Attribute
- Component Services and Component References can specify an optional sy:security attribute. This attribute points to a named <security> element in the domain section. If not defined, use the default value.
- The callbackHandler Attribute
- This is an optional attribute. If not specified, use the default value of
org.switchyard.security.callback.NamePasswordCallbackHandler
. - The name Attribute
- This is an optional attribute. If not specified, use the default value of default. Component Services and Component References point to this name.
- The rolesAllowed Attribute
- This is an optional attribute. If specified, and if a Service has an authorization security policy requirement, the authenticated user must be in one of the roles listed.
- The runAs Attribute
- This is an optional attribute. If specified, add the value of this attribute as a role to the authenticated user.
- The securityDomain Attribute
- This is an optional attribute. If not specified, use the default value.
- The <properties> and <property> Elements
- A <security> element can optionally specify a <properties> element, which can optionally specify zero to many <property> elements. Each <property> element has two required attributes: name and value. The list of specified name/value properties are made available to the SwitchYard Security configuration, as well as the configured callbackHandler.
- The <securities> Element
- This is an optional element. Contains any number of <security> elements. If not defined, use the default security configuration.
- The <security> Element
- This is an optional element. If not specified, the callbackHandler, name, and securityDomain attributes will fallback to their default values.
1.5. Security
1.6. Callback Handlers
org.switchyard.security.callback
Java package:
- NamePasswordCallbackHandler
- Provides name and password credentials to a configured LoginModule stack.
- STSTokenCallbackHandler
- Provides assertion credentials to a configured LoginModule stack.
- STSIssueCallbackHandler
- Utilizes the NamePasswordCallbackHandler and the STSTokenCallbackHandler to provide name, password and assertion credentials to a configured LoginModule stack.
- CertificateCallbackHandler
- Provides Certificate credentials to a configured LoginModule stack.
1.7. Login Modules
1.8. SwitchYard Security Quickstarts
Note
EAP_HOME/quickstarts/switchyard/demos
directory. You can find out more information from the Readme.md
file packaged with each.
- policy-security-basic
- This quickstart exposes a bean service through a soap binding. Confidentiality is provided via SSL, and client authentication via a HTTP Basic Authorization header.
- policy-security-basic-propagate
- This quickstart is similar to policy-security-basic, however the bean service additionally invokes a different back end bean service which also has security policy requirements. The client's security context (authenticated subject and credentials) is propagated to this secondary service.
- policy-security-cert
- This quickstart exposes a bean service through a soap binding. Confidentiality is provided via SSL, and client authentication via an X509 Certificate.
- policy-security-saml
- This quickstart exposes a bean service through a soap binding. Confidentiality is provided via SSL, and client authentication via a SAML assertion in the form of a token retrieved from PicketLink STS.
- policy-security-wss-signencrypt
- This quickstart exposes a bean service through a soap binding. Proper Signature and Encryption are enforced by JBossWS-CXF.
- policy-security-wss-username
- This quickstart exposes a bean service through a soap binding. Confidentiality is provided via SSL, and client authentication via a WS-Security UsernameToken which is handled by JBossWS-CXF.
1.9. Secure Ways of Running Red Hat JBoss Fuse Service Works
- If you run Red Hat JBoss Fuse Service Works without Runtime Governance, you can disable JSM as it does not introduce MVEL security risks.
- If you need Runtime Governance in high performance environment, Red Hat recommends running Runtime Governance in a separate JVM. The JVM instance running Runtime Governance must have JSM enabled, whereas other application server instances can run without JSM.
- If you are working on testing and development environments without high loads, it is okay to run one JVM with the server, Runtime Governance, and JSM enabled as the performance hit is not dramatic.
Warning
Chapter 2. Patch Installation
2.1. About Patching Mechanisms
- Asynchronous updates: one-off patches which are released outside the normal update cycle of the existing product. These may include security patches, as well as other one-off patches provided by Red Hat Global Support Services (GSS) to fix specific issues.
- Planned updates: These include cumulative patches, as well as micro, minor or major upgrades of an existing product. Cumulative patches include all previously developed asynchronous updates for that version of the product.
Important
2.2. Subscribe to Patch Mailing Lists
The JBoss team at Red Hat maintains a mailing list for security announcements for Red Hat JBoss Enterprise Middleware products. This section covers what you need to do to subscribe to this list.
Prerequisites
- None
Procedure 2.1. Subscribe to the JBoss Watch List
- Click the following link to go to the JBoss Watch mailing list page: JBoss Watch Mailing List.
- Enter your email address in the Subscribing to Jboss-watch-list section.
- [You may also wish to enter your name and select a password. Doing so is optional but recommended.]
- Press thebutton to start the subscription process.
- You can browse the archives of the mailing list by going to: JBoss Watch Mailing List Archives.
After confirmation of your email address, you will be subscribed to receive security related announcements from the JBoss patch mailing list.
2.3. Install Patches in zip form
JBoss bug fix patches are distributed in zip format. This task describes the steps you need to take to install the patches (security or bug fixes) via the zip format.
Prerequisites
- Valid access and subscription to the Red Hat Customer Portal.
- A current subscription to a JBoss product installed in a zip format.
Procedure 2.2. Apply a patch to a JBoss product via the zip method
Warning
- Get notified about the security patch either via being a subscriber to the JBoss watch mailing list or by browsing the JBoss watch mailing list archives.
Note
Only security patches are announced on the JBoss watch mailing list. - Read the ERRATA for the security patch and confirm that it applies to a JBoss product in your environment.
- If the security patch applies to a JBoss product in your environment, then follow the link to download the patch from the Red Hat Customer Portal.
- The downloadable zip file from the customer portal will contain all the files required to fix the security issue or bug. Download this patch zip file in the same location as your JBoss product.
- Unzip the patch file in the same location where the JBoss product is installed. The patched versions overwrite the existing files.
The JBoss product is patched with the latest update using the zip format.
2.4. Severity and Impact Rating of JBoss Security Patches
Severity | Description |
---|---|
Critical |
This rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. These are the types of vulnerabilities that can be exploited by worms. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as critical impact.
|
Important |
This rating is given to flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the types of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow local or remote users to cause a denial of service.
|
Moderate |
This rating is given to flaws that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. These are the types of vulnerabilities that could have had a critical impact or important impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.
|
Low |
This rating is given to all other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences.
|
Example 2.1. CVSS v2 Impact Score
C:N/I:P/A:C
Chapter 3. Known Security Issues
3.1. The Poodle Issue and JBoss Fuse Service Works
Note
Chapter 4. WS-Security
4.1. WS-Security Overview
- Pass authentication tokens between services
- Encrypt messages or parts of messages
- Sign messages
- Timestamp messages
4.2. JBoss WS-Security Support
4.3. Apache CXF WS-Security Implementation
4.3.1. WS-Security Policy Support
Property | Description |
---|---|
ws-security.username |
The username used for UsernameToken policy assertions.
|
ws-security.password |
The password used for UsernameToken policy assertions. If not specified, the callback handler is called.
|
ws-security.callback-handler |
The WSS4J security CallbackHandler that is used to retrieve passwords for keystores and UsernameTokens.
|
ws-security.signature.properties |
The properties file or object that contains the WSS4J properties for configuring the signature keystore and crypto objects.
|
ws-security.encryption.properties |
The properties file or object that contains the WSS4J properties for configuring the encryption keystore and crypto objects.
|
ws-security.signature.username |
The username or alias for the key in the signature keystore. If not specified, it uses the default alias set in the properties file. If that is also not set, and the keystore only contains a single key, that key is used.
|
ws-security.encryption.username |
The username or alias for the key in the encryption keystore. If not specified, it uses the default alias set in the properties file. If that is also not set, and the keystore only contains a single key, that key is used. For the web service provider, the useReqSigCert keyword can be used to accept (encrypt to) any client whose public key is in the service's truststore (defined in
ws-security.encryption.properties .)
|
ws-security.signature.crypto |
Instead of specifying the signature properties, this can point to the full WSS4J Crypto object. This can allow easier programmatic configuration of the Crypto information.
|
ws-security.encryption.crypto |
Instead of specifying the encryption properties, this can point to the full WSS4J Crypto object. This can allow easier programmatic configuration of the Crypto information.
|
Map<String, Object> ctx = ((BindingProvider)port).getRequestContext(); ctx.put("ws-security.encryption.properties", properties); port.echoString("hello");
4.3.2. JBossWS Configuration Additions
<?xml version="1.0" encoding="UTF-8"?> <jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee" xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd"> <endpoint-config> <config-name>Custom WS-Security Endpoint</config-name> <property> <property-name>ws-security.signature.properties</property-name> <property-value>bob.properties</property-value> </property> <property> <property-name>ws-security.encryption.properties</property-name> <property-value>bob.properties</property-value> </property> <property> <property-name>ws-security.signature.username</property-name> <property-value>bob</property-value> </property> <property> <property-name>ws-security.encryption.username</property-name> <property-value>alice</property-value> </property> <property> <property-name>ws-security.callback-handler</property-name> <property-value>org.jboss.test.ws.jaxws.samples.wsse.policy.basic.KeystorePasswordCallback</property-value> </property> </endpoint-config> </jaxws-config>
import javax.jws.WebService; import org.jboss.ws.api.annotation.EndpointConfig; @WebService ( portName = "SecurityServicePort", serviceName = "SecurityService", wsdlLocation = "WEB-INF/wsdl/SecurityService.wsdl", targetNamespace = "http://www.jboss.org/jbossws/ws-extensions/wssecuritypolicy", endpointInterface = "org.jboss.test.ws.jaxws.samples.wsse.policy.basic.ServiceIface" ) @EndpointConfig(configFile = "WEB-INF/jaxws-endpoint-config.xml", configName = "Custom WS-Security Endpoint") public class ServiceImpl implements ServiceIface { public String sayHello() { return "Secure Hello World!"; } }
4.3.3. Apache CXF Annotations
@WebService( ... ) @EndpointProperties(value = { @EndpointProperty(key = "ws-security.signature.properties", value = "bob.properties"), @EndpointProperty(key = "ws-security.encryption.properties", value = "bob.properties"), @EndpointProperty(key = "ws-security.signature.username", value = "bob"), @EndpointProperty(key = "ws-security.encryption.username", value = "alice"), @EndpointProperty(key = "ws-security.callback-handler", value = "org.jboss.test.ws.jaxws.samples.wsse.policy.basic.KeystorePasswordCallback") } ) public class ServiceImpl implements ServiceIface { ... }
4.4. Enable WS-Security
Procedure 4.1. Enable WS-Security
- Define a Policy within your WSDL and reference it with a PolicyReference inside your binding.
- Configure your <soap.binding> with <securityAction>.This is so that JBossWS-CXF knows which tokens to respect within incoming SOAP requests.
- Include a
WEB-INF/jboss-web.xml
file in your application with a <security-domain> specified.This is so that JBossWS-CXF knows which modules to use for authentication and rolemapping.
4.5. Sample WS-Security Configurations
policy-security-wss-username
quickstart application as an example. The following are the pertinent sections:
META-INF/WorkService.wsdl
:<binding name="WorkServiceBinding" type="tns:WorkService"> <wsp:PolicyReference URI="#WorkServicePolicy"/> ... </binding> <wsp:Policy wsu:Id="WorkServicePolicy"> <wsp:ExactlyOne> <wsp:All> <sp:SupportingTokens xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"> <wsp:Policy> <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"> <wsp:Policy> <sp:WssUsernameToken10/> </wsp:Policy> </sp:UsernameToken> </wsp:Policy> </sp:SupportingTokens> </wsp:All> </wsp:ExactlyOne> </wsp:Policy>
META-INF/switchyard.xml
:<binding.soap xmlns="urn:switchyard-component-soap:config:1.0"> <wsdl>META-INF/WorkService.wsdl</wsdl> <contextPath>policy-security-wss-username</contextPath> <endpointConfig configFile="META-INF/jaxws-endpoint-config.xml" configName="SwitchYard-Endpoint-Config"/> <inInterceptors> <interceptor class="org.jboss.wsf.stack.cxf.security.authentication.SubjectCreatingPolicyInterceptor"/> </inInterceptors> </binding.soap>
META-INF/jaxws-endpoint-config.xml
:<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:javaee="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd"> <endpoint-config> <config-name>SwitchYard-Endpoint-Config</config-name> <property> <property-name>ws-security.validate.token</property-name> <property-value>false</property-value> </property> </endpoint-config> </jaxws-config>
WEB-INF/jboss-web.xml
:<jboss-web> <security-domain>java:/jaas/other</security-domain> </jboss-web>
UsernameToken
, attempt to authenticate it against the LoginModule(s) configured in the application server's "other" security domain, and provide any authorized roles. If successful, the request is handed over to SwitchYard, which processes it further, including enforcing your own policies. In the case of WS-Security, SwitchYard does not attempt a second clientAuthentication, but instead respects the outcome from JBossWS-CXF.
Note
4.6. Signature and Encryption Support
- Include the added requirements to the Policy in your WSDL. See Section 4.7, “Sample Endpoint Configurations”, Section 4.8, “Sample Client Configurations”, and Section 4.9, “Endpoint Serving Multiple Clients”.
- Add a CXF Interceptor which sets certain CXF security properties. See Section 4.10, “Sample CXF Interceptor Configurations”.
4.7. Sample Endpoint Configurations
- Create the web service endpoint using JAX-WS. Use a contract-first approach when using WS-Security as the policies declared in the WSDL are parsed by the Apache CXF engine on both server and client sides. Here is an example of WSDL contract enforcing signature and encryption using X 509 certificates:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <definitions targetNamespace="http://www.jboss.org/jbossws/ws-extensions/wssecuritypolicy" name="SecurityService" xmlns:tns="http://www.jboss.org/jbossws/ws-extensions/wssecuritypolicy" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsaws="http://www.w3.org/2005/08/addressing" xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <types> <xsd:schema> <xsd:import namespace="http://www.jboss.org/jbossws/ws-extensions/wssecuritypolicy" schemaLocation="SecurityService_schema1.xsd"/> </xsd:schema> </types> <message name="sayHello"> <part name="parameters" element="tns:sayHello"/> </message> <message name="sayHelloResponse"> <part name="parameters" element="tns:sayHelloResponse"/> </message> <portType name="ServiceIface"> <operation name="sayHello"> <input message="tns:sayHello"/> <output message="tns:sayHelloResponse"/> </operation> </portType> <binding name="SecurityServicePortBinding" type="tns:ServiceIface"> <wsp:PolicyReference URI="#SecurityServiceSignThenEncryptPolicy"/> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/> <operation name="sayHello"> <soap:operation soapAction=""/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="SecurityService"> <port name="SecurityServicePort" binding="tns:SecurityServicePortBinding"> <soap:address location="http://localhost:8080/jaxws-samples-wssePolicy-sign-encrypt"/> </port> </service> <wsp:Policy wsu:Id="SecurityServiceSignThenEncryptPolicy" xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <wsp:ExactlyOne> <wsp:All> <sp:AsymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <wsp:Policy> <sp:InitiatorToken> <wsp:Policy> <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient"> <wsp:Policy> <sp:WssX509V1Token11/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:InitiatorToken> <sp:RecipientToken> <wsp:Policy> <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never"> <wsp:Policy> <sp:WssX509V1Token11/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:RecipientToken> <sp:AlgorithmSuite> <wsp:Policy> <sp-cxf:Basic128GCM xmlns:sp-cxf="http://cxf.apache.org/custom/security-policy"/> </wsp:Policy> </sp:AlgorithmSuite> <sp:Layout> <wsp:Policy> <sp:Lax/> </wsp:Policy> </sp:Layout> <sp:IncludeTimestamp/> <sp:EncryptSignature/> <sp:OnlySignEntireHeadersAndBody/> <sp:SignBeforeEncrypting/> </wsp:Policy> </sp:AsymmetricBinding> <sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <sp:Body/> </sp:SignedParts> <sp:EncryptedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <sp:Body/> </sp:EncryptedParts> <sp:Wss10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <wsp:Policy> <sp:MustSupportRefIssuerSerial/> </wsp:Policy> </sp:Wss10> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> </definitions>
You can generate the service endpoint using the wsconsume tool and then use a @EndpointConfig annotation as shown below:package org.jboss.test.ws.jaxws.samples.wsse.policy.basic; import javax.jws.WebService; import org.jboss.ws.api.annotation.EndpointConfig; @WebService ( portName = "SecurityServicePort", serviceName = "SecurityService", wsdlLocation = "WEB-INF/wsdl/SecurityService.wsdl", targetNamespace = "http://www.jboss.org/jbossws/ws-extensions/wssecuritypolicy", endpointInterface = "org.jboss.test.ws.jaxws.samples.wsse.policy.basic.ServiceIface" ) @EndpointConfig(configFile = "WEB-INF/jaxws-endpoint-config.xml", configName = "Custom WS-Security Endpoint") public class ServiceImpl implements ServiceIface { public String sayHello() { return "Secure Hello World!"; } }
- Use the referenced
jaxws-endpoint-config.xml
descriptor to provide a custom endpoint configuration with the required server side configuration properties as shown below. This tells the engine which certificate or key to use for signature, signature verification, encryption, and decryption.<?xml version="1.0" encoding="UTF-8"?> <jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee" xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd"> <endpoint-config> <config-name>Custom WS-Security Endpoint</config-name> <property> <property-name>ws-security.signature.properties</property-name> <property-value>bob.properties</property-value> </property> <property> <property-name>ws-security.encryption.properties</property-name> <property-value>bob.properties</property-value> </property> <property> <property-name>ws-security.signature.username</property-name> <property-value>bob</property-value> </property> <property> <property-name>ws-security.encryption.username</property-name> <property-value>alice</property-value> </property> <property> <property-name>ws-security.callback-handler</property-name> <property-value>org.jboss.test.ws.jaxws.samples.wsse.policy.basic.KeystorePasswordCallback</property-value> </property> </endpoint-config> </jaxws-config>
Here,- The
bob.properties
configuration file includes the WSS4J Crypto properties which in turn links to the keystore file, type, alias, and password for accessing it. For example:org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin org.apache.ws.security.crypto.merlin.keystore.type=jks org.apache.ws.security.crypto.merlin.keystore.password=password org.apache.ws.security.crypto.merlin.keystore.alias=bob org.apache.ws.security.crypto.merlin.keystore.file=bob.jks
- The callback handler enables Apache CXF to access the keystore. For example:
package org.jboss.test.ws.jaxws.samples.wsse.policy.basic; import java.io.IOException; import java.util.HashMap; import java.util.Map; import javax.security.auth.callback.Callback; import javax.security.auth.callback.CallbackHandler; import javax.security.auth.callback.UnsupportedCallbackException; import org.apache.ws.security.WSPasswordCallback; public class KeystorePasswordCallback implements CallbackHandler { private Map<String, String> passwords = new HashMap<String, String>(); public KeystorePasswordCallback() { passwords.put("alice", "password"); passwords.put("bob", "password"); } /** * It attempts to get the password from the private * alias/passwords map. */ public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException { for (int i = 0; i < callbacks.length; i++) { WSPasswordCallback pc = (WSPasswordCallback)callbacks[i]; String pass = passwords.get(pc.getIdentifier()); if (pass != null) { pc.setPassword(pass); return; } } } /** * Add an alias/password pair to the callback mechanism. */ public void setAliasPassword(String alias, String password) { passwords.put(alias, password); } }
- Assuming the
bob.jks
keystore is properly generated and contains the server Bob's full key as well as the client Alice's public key, you can proceed to packaging the endpoint. Here is the expected content:/dati/jbossws/stack/cxf/trunk $ jar -tvf ./modules/testsuite/cxf-tests/target/test-libs/jaxws-samples-wsse-policy-sign-encrypt.war 0 Thu Jun 16 18:50:48 CEST 2011 META-INF/ 140 Thu Jun 16 18:50:46 CEST 2011 META-INF/MANIFEST.MF 0 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/ 586 Thu Jun 16 18:50:44 CEST 2011 WEB-INF/web.xml 0 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/ 0 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/ 0 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/jboss/ 0 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/jboss/test/ 0 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/jboss/test/ws/ 0 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/jboss/test/ws/jaxws/ 0 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/jboss/test/ws/jaxws/samples/ 0 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsse/ 0 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsse/policy/ 0 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsse/policy/basic/ 1687 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsse/policy/basic/KeystorePasswordCallback.class 383 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsse/policy/basic/ServiceIface.class 1070 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsse/policy/basic/ServiceImpl.class 0 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsse/policy/jaxws/ 705 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsse/policy/jaxws/SayHello.class 1069 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/jboss/test/ws/jaxws/samples/wsse/policy/jaxws/SayHelloResponse.class 1225 Thu Jun 16 18:50:44 CEST 2011 WEB-INF/jaxws-endpoint-config.xml 0 Thu Jun 16 18:50:44 CEST 2011 WEB-INF/wsdl/ 4086 Thu Jun 16 18:50:44 CEST 2011 WEB-INF/wsdl/SecurityService.wsdl 653 Thu Jun 16 18:50:44 CEST 2011 WEB-INF/wsdl/SecurityService_schema1.xsd 1820 Thu Jun 16 18:50:44 CEST 2011 WEB-INF/classes/bob.jks 311 Thu Jun 16 18:50:44 CEST 2011 WEB-INF/classes/bob.properties
Here, the jaxws classes generated by the tools and a basic web.xml referencing the endpoint bean are also included:<?xml version="1.0" encoding="UTF-8"?> <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"> <servlet> <servlet-name>TestService</servlet-name> <servlet-class>org.jboss.test.ws.jaxws.samples.wsse.policy.basic.ServiceImpl</servlet-class> </servlet> <servlet-mapping> <servlet-name>TestService</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping> </web-app>
Note
If you are deploying the endpoint archive to JBoss Application Server 7, add a dependency toorg.apache.ws.security
module in theMANIFEST.MF
file:Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.1 Created-By: 17.0-b16 (Sun Microsystems Inc.) Dependencies: org.apache.ws.security
4.8. Sample Client Configurations
QName serviceName = new QName("http://www.jboss.org/jbossws/ws-extensions/wssecuritypolicy", "SecurityService"); URL wsdlURL = new URL(serviceURL + "?wsdl"); Service service = Service.create(wsdlURL, serviceName); ServiceIface proxy = (ServiceIface)service.getPort(ServiceIface.class); ((BindingProvider)proxy).getRequestContext().put(SecurityConstants.CALLBACK_HANDLER, new KeystorePasswordCallback()); ((BindingProvider)proxy).getRequestContext().put(SecurityConstants.SIGNATURE_PROPERTIES, Thread.currentThread().getContextClassLoader().getResource("META-INF/alice.properties")); ((BindingProvider)proxy).getRequestContext().put(SecurityConstants.ENCRYPT_PROPERTIES, Thread.currentThread().getContextClassLoader().getResource("META-INF/alice.properties")); ((BindingProvider)proxy).getRequestContext().put(SecurityConstants.SIGNATURE_USERNAME, "alice"); ((BindingProvider)proxy).getRequestContext().put(SecurityConstants.ENCRYPT_USERNAME, "bob"); proxy.sayHello();The WS-Security properties are set in the request context. Here, the
KeystorePasswordCallback
is same as that on the server side. The alice.properties
file is the client side equivalent of the server side bob.properties
file and references the alice.jks
keystore file, which has been populated with client Alice's full key as well as server Bob's public key:
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin org.apache.ws.security.crypto.merlin.keystore.type=jks org.apache.ws.security.crypto.merlin.keystore.password=password org.apache.ws.security.crypto.merlin.keystore.alias=alice org.apache.ws.security.crypto.merlin.keystore.file=META-INF/alice.jksThe Apache CXF WS-Policy engine consumes the security requirements in the contract and ensures that a valid secure communication is in place for interacting with the server endpoint.
4.9. Endpoint Serving Multiple Clients
useReqSigCert
value for the ws-security.encryption.username
configuration parameter. The referenced server side keystore then needs to contain the public key of all the clients that are expected to be served.
4.10. Sample CXF Interceptor Configurations
META-INF/switchyard.xml
<binding.soap xmlns="urn:switchyard-component-soap:config:1.0"> <wsdl>META-INF/WorkService.wsdl</wsdl> <contextPath>policy-security-wss-username</contextPath> <inInterceptors> <interceptor class="com.example.MyInterceptor"/> </inInterceptors> </binding.soap>
com/example/MyInterceptor.java
public class MyInterceptor extends WSS4JInterceptor { private static final PROPS; static { Map<String,String> props = new HashMap<String,String>(); props.put("action", "Signature Encryption"); props.put("signaturePropFile", "META-INF/bob.properties"); props.put("decryptionPropFile", "META-INF/bob.properties"); props.put("passwordCallbackClass", "com.example.MyCallbackHandler"); PROPS = props; } public MyInterceptor() { super(PROPS); } }
META-INF/bob.properties
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin org.apache.ws.security.crypto.merlin.keystore.type=jks org.apache.ws.security.crypto.merlin.keystore.password=password org.apache.ws.security.crypto.merlin.keystore.alias=bob org.apache.ws.security.crypto.merlin.file=META-INF/bob.jks
Chapter 5. S-RAMP Security
5.1. S-RAMP Browser
5.1.1. S-RAMP Browser Authentication
- Security domain configuration (for both S-RAMP Browser and S-RAMP Server)
- Web based single-sign-on configuration
- IDP web application configuration
- Managing Admin user
5.1.2. S-RAMP Browser Authorization
overlorduser
5.2. S-RAMP Server
- JCR (ModeShape): Used as the persistence engine, where all S-RAMP data is stored. Artifacts and ontologies are both stored as nodes in a JCR tree. All S-RAMP queries are mapped to JCRSQL2 queries for processing by the JCR API. The ModeShape JCR implementation is used by default. However, the persistence layer is pluggable allowing alternative providers to be implemented in the future.
- JAX-RS (RESTEasy): Used to provide the S-RAMP Atom based REST API. The S-RAMP specification documents an Atom based REST API that implementations should make available. The S-RAMP implementation uses JAX-RS (specifically RESTEasy) to expose all of the REST endpoints defined by the specification.
- JAXB: Used to expose a Java data model based on the S-RAMP data structures defined by the specification (S-RAMP XSD schemas).
5.2.1. S-RAMP Server Authorization
admin.sramp
overlorduser
Chapter 6. Policy
6.1. About Policy
6.2. Configuring Policy
- Policy that the service provider requires
- Policy support that the service consumer provides
<composite name="policy-transaction"> <service name="WorkService" promote="WorkService"> <camel:binding.camel configURI="jms://policyQSTransacted?connectionFactory=%23JmsXA&transactionManager=%23jtaTransactionManager&transacted=true"/> <camel:binding.camel configURI="jms://policyQSNonTransacted?connectionFactory=#ConnectionFactory"/> </service> <component name="WorkService"> <implementation.bean class="org.switchyard.quickstarts.demo.policy.transaction.WorkServiceBean" requires="managedTransaction.Global"/> <service name="WorkService" requires="propagatesTransaction"> <interface.java interface="org.switchyard.quickstarts.demo.policy.transaction.WorkService"/> </service> <reference name="TaskAService" requires="propagatesTransaction"> <interface.java interface="org.switchyard.quickstarts.demo.policy.transaction.TaskAService"/> </reference> </component> </composite>
6.3. Interaction Policy
requires
attribute. You can use the Interaction policy on component service and component reference and is not allowed to be marked on component implementation. This policy enables you to manage the communication between the service provider and consumer.
6.4. Implementation Policy
requires
attribute. You can use the Implementation policy on component implementation and is not allowed to be marked on component service nor component reference.
6.5. Transaction Policy
6.5.1. Transaction Interaction Policy
requires
attribute. Here is an example:
<service name="WorkService" requires="propagatesTransaction">
propagatesTransaction
: Indicates that a global transaction is required when a service is invoked. If no transaction is present, the SwitchYard generates an error at runtime.suspendsTransaction
: Indicates that if a transaction exists, the SwitchYard runtime suspends it before the service implementation is invoked and resumes it after the service invocation. This setting allows you to separate a gateway binding's transactional context from the transactional context of the service implementation.
propagatesTransaction
and suspendsTransaction
intents either to an interface or explicitly to a service and reference XML element in order to describe how any client transaction context is made available and used by the target service component.
Figure 6.1. Transaction Interaction Policy
6.5.2. Transaction Implementation Policy
requires
attribute. Here is an example:
<implementation.bean class="org.switchyard.quickstarts.demo.policy.transaction.WorkServiceBean" requires="managedTransaction.Global">
managedTransaction.Global
: Indicates that this service implementation runs under a global transaction. If no transaction is present, the SwitchYard runtime creates a new JTA transaction before the execution. The SwitchYard runtime commits this newly created transaction at the end of service execution.managedTransaction.Local
: Indicates that this service implementation runs under a local transaction. If a transaction exists, the SwitchYard runtime suspends it. SwitchYard always creates a new JTA transaction before execution. The SwitchYard runtime commits this newly created transaction and resumes the suspended transcation after the service invocation.Note
As the local transaction does not propagate its transaction through the reference, you must mark all of the component reference assuspendsTransaction
. If not, the SwitchYard runtime generates an error.noManagedTransaction
: Indicates that this service implementation does not run under any managed transaction. If a transaction exists, the SwitchYard runtime suspends it before the service implementation is invoked and resumes it after the service invocation.
managedTransaction
and noManagedTransaction
intents to describe the transactional environment required by a service component.
Currently, the following gateways are transaction aware:
- Camel JMS Gateway (binding.jms)
- Camel JPA Gateway (binding.jpa)
- Camel SQL Gateway (binding.sql)
- JCA Gateway (binding.jca)
- SCA Gateway (binding.sca)
Note
Note
Figure 6.2. Transaction Implementation Policy
6.6. Security Policy
Note
- security.policy- It defines a JVM level permitAll policy.
- kie.policy- It is used by Rule-based services.
- rtgov.policy- It is used for the Runtime Governance REST API.
Note
6.6.1. Security Interaction Policy
requires
attribute of a component service definition.
<service name="WorkService" requires="authorization clientAuthentication confidentiality">
- clientAuthentication: indicates that the client has been authenticated when a service is invoked. If the associated authenticated user principal is not available, SwitchYard runtime generates an error.
- confidentiality: indicates that the request has been made over a secure channel. When a SOAP request is made over SSL and its confidentiality is not verified, SwitchYard runtime generates an error,
Figure 6.3. Security Interaction Policy
6.6.2. Security Implementation Policy
- authorization: indicates that the client is authorized to invoke the service. If the associated authenticated subject does not have an allowed role, SwitchYard runtime generates an error.
Figure 6.4. Security Implementation Policy
6.6.3. Setting Security Policy
- Edit the SwitchYard application descriptor (
switchyard.xml
) and add therequires
attribute to a service definition.
- Use the
@Requires
attribute in your service implementation to declare security policy for the service. When the application project is built, the SwitchYard application finds@Requires
annotations and automatically generates the required configuration.
6.6.4. Security Processing
switchyard.xml
.
<switchyard> <domain> <security callbackHandler="callback-handler-class-name" moduleName"="jaas-domain-name" rolesAllowed="users, administrators" runAs="leaders"> <properties> <property name="property-name" value="property-value"/> </properties> </security> </domain> </switchyard>
Note
Appendix A. Revision History
Revision History | |||
---|---|---|---|
Revision 6.0.0-28 | Monday February 23 2015 | ||
| |||
Revision 6.0.0-27 | Tuesday January 13 2015 | ||
| |||
Revision 6.0.0-26 | Wednesday December 17 2014 | ||
|