The <component><service> and <component><reference> security Attribute

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.

The <securities> Element

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.

The <security> Element

This is an optional element.  If not specified, the callbackHandler, name, and securityDomain 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.  See the Callback Handlers section below for details on CallbackHandlers.

The name Attribute

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.

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 securityDomain 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.  See the Login Modules section below for details on LoginModules.

The <properties> and <property> Elements

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.

Callback Handlers

The following is a list of available CallbackHandlers, all within the org.switchyard.security.callback java package:

Login Modules

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>

Subsystem Configuration Elements

Security-specific configuration details for the SwitchYard JBoss Subsystem.

<subsystem xmlns="urn:jboss:domain:switchyard:1.0">
    <security-configs>
        <security-config identifier="org.switchyard.security.context.SecurityContext">
            <properties>
                <timeoutMillis>30000</timeoutMillis>
            </properties>
        </security-config>
    </security-configs>
</subsystem>

<subsystem xmlns="urn:jboss:domain:switchyard:1.0">
    <security-configs>
        <security-config identifier="org.switchyard.security.crypto.PrivateCrypto">
            <properties>
                <sealAlgorithm>TripleDES</sealAlgorithm>
                <sealKeySize>168</sealKeySize>
            </properties>
        </security-config>
    </security-configs>
</subsystem>

Storing Passwords

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:

1. 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.

2. Wherever you would normally include a password value in your switchyard.xml, use the vault ID instead, e.g.

${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}