SwitchYard services can be secured by:
- Specifying a list of security policies that are required for that service. See the Security Policy section of the documentation for details.
- Configuring application-level security processing details for the services within a domain. See Application Security Configuration below for details.
- Configuring system-level security processing details. See System Security Configuration below for details.
- Storing sensitive information, such as passwords, in the JBoss AS password vault. See the Storing Passwords section for details.
All services within a domain can share - or define their own - security configuration:
, which is specified in META-INF/switchyard.xml:
Component Services and Component References can specify an optional sy:security attribute (namespace prefix required, as the SCA schema is being extended). This attribute points to a named <security> element in the domain section. If not defined, default will be inferred.
This is an optional element. Contains any number of <security> elements. If not defined, a default security configuration is still used. See the <security> element below.
This is an optional element. If not specified, the callbackHandler, name, and securityDomain attributes described below will fallback to their default values.
This is an optional attribute. If not specified, a default value of org.switchyard.security.callback.NamePasswordCallbackHandler will be used. See the Callback Handlers section below for details on CallbackHandlers.
This is an optional attribute. If not specified, a default value of default will be used. Component Services and Component References point to this name.
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).
This is an optional attribute. If specified, the value of this attribute will be added as a role to the authenticated user.
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. See the Login Modules section below for details on LoginModules.
A <security> element can optionally specify a <properties> element, which can optionally specify zero to many (0..*) <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. Some CallbackHandlers require configuration information beyond what can be assumed in a no-argument constructor. See the individual CallbackHandler implementations for details.
The following is a list of available CallbackHandlers, all within the org.switchyard.security.callback java package:
Provides name and password credentials to a configured LoginModule stack. For example, the UsersRoles LoginModule that comes out-of-the-box in JBoss AS7.
Provides assertion credentials to a configured LoginModule stack. For example, the PicketLink STSValidatingLoginModule that comes out-of-the-box in JBoss AS7.
Wraps both the NamePasswordCallbackHandler and the STSTokenCallbackHandler, so as to provide name, password and assertion credentials to a configured LoginModule stack. For example the UsersRoles LoginModule and STSIssuingLoginModule that comes out-of-the-box in JBoss AS7.
Provides Certificate credentials to a configured LoginModule stack. SwitchYard 0.7+ provides a CertificateLoginModule for this purpose.
These are settings that apply to the entire running instance of SwitchYard (within the application server).
In JBoss AS7, JAAS LoginModules can be stacked underneath a single security domain, and other is available out-of-the-box. Here is an example that could be added to jboss-as7/standalone/configuration/standalone.xml:
Please refer to the LoginModule documentation directly for complete configuration details, however a couple will be provided as example here.
Simple users/roles properties files on the classpath:
Security Token Service validation:
Security-specific configuration details for the SwitchYard JBoss Subsystem.
A SecurityContext is a SwitchYard-internal construct that maintains information regarding a client's authenticated Subject for what security domains, as well as a list of built-up credentials (think name, password, certificate, etc). This security context, by default, does not expire, however is only valid within the current running instance of SwitchYard. That is to say, if an invocation crosses a process or network boundary, re-authentication and authorization checks will need to be re-done. That being said, you can configure the security context to expire after a specified number of milliseconds. To do that, within your AS standalone.xml file, add the appropriate security-config section, as shown below:
Sensitive data within the JVM - including the SecurityContext mentioned above - can be encrypted as well, such that sneaky applications can't access sensitive user credentials. Configuring encryption is a security-system-wide endeavor, and can be done adding the appropriate security-config section, as shown below:
Note that acceptable values for sealAlgorithm and sealKeySize will depend upon the capabilities of your JVM.
The SwitchYard distribution contains security examples in the form of quickstart demos:
- 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. See the Readme.md file for details.
- 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. See the Readme.md file for details.
- 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. See the Readme.md file for details.
- policy-security-wss-signencrypt: This quickstart exposes a bean service through a soap binding. Proper Signature and Encryption are enforced by JBossWS-CXF. See the Readme.md file for details.
- 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. See the Readme.md file for details.
Instead of storing plain-text passwords in switchyard.xml, you can use a combination of the JBoss AS password vault and property substitution in SwitchYard to obscure the password value. There are two steps involved with this approach:
- Configure the AS password vault and store your password information in the vault following the instructions documented on the JBoss AS7 Securing Passwords page. Please pay special attention to the warnings on the page which indicate the level of security protection provided by the default password vault implementation.
- Wherever you would normally include a password value in your switchyard.xml, use the vault ID instead, e.g.