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 the security processing details for the services within a domain. See Security Configuration below for details.
All services within a domain share the same security configuration, which is specified in 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>
This is an optional element. If not specified, the callbackHandler and moduleName 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 o CallbackHandlers.
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.
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.
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.
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:
<server>
<profile>
<subsystem xmlns="urn:jboss:domain:security:1.1">
<security-domains>
<security-domain name="jaas-domain-name" cache-type="default">
<authentication>
<login-module code="login-module-class-name-or-shorthand-name" flag="required">
<module-option name="option-name" value="option-value"/>
</login-module>
</authentication>
</security-domain>
</security-domains>
</subsystem>
</profile>
</server>
JBoss AS7 bundles various PicketBox (underlying security capability) LoginModules, as well as various PicketLink (federated trust security capability) LoginModules.
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:
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties" value="users.properties"/>
<module-option name="rolesProperties" value="roles.properties"/>
</login-module>
Security Token Service validation:
<login-module code="org.picketlink.identity.federation.core.wstrust.auth.STSValidatingLoginModule" flag="required">
<module-option name="configFile" value="../standalone/configuration/sts-client.properties"/>
<module-option name="useOptionsCredentials" value="true"/>
</login-module>
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-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-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.