Using SCA authorization and security identity policies (deprecated)

Use two Service Component Architecture (SCA) declarative policies (authorization and security identity) to protect SCA components and operations and to declare the security identity under which the SCA components or operations are executed.

Deprecated feature: 8.5.5.19 or later

The Service Component Architecture (SCA) programming model and samples are deprecated, and will be removed in a future release. You cannot deploy new SCA business-level applications. If you want to continue to use SCA as part of your long-term strategy, consider hosting your applications on IBM Business Process Manager.

Before you begin

A user registry must be configured and an SCA component must first have been developed. You must also enable application security.

About this task

An authorization policy controls who can access protected SCA components and operations. A security identity policy declares the security identity under which an SCA component or operation is executed. You can limit access to an SCA component or to an operation to particular users or groups. You can also delegate access to another user when executing an SCA component or an operation.

Note the following limitations:

SCA authorization policy is not supported for composites packaged in web application archives (WAR files).
The definitions.xml file must be packaged in the same asset as the composites that reference its policy sets.
For OASIS SCA applications, definitions.xml must be packaged in the same asset as the composites that reference its policy sets under the META-INF directory.
Role assignments are scoped to a configuration unit, and are required for all of the roles used in all of the composites within the configuration unit. These role assignments are completely independent of any role assignments made for other configuration units in the same business-level application.
The target namespace of the policy set and the name of the policy set do not contribute to the name of a role. They are used solely to resolve the policy set reference. This implies that within the same configuration unit, identically-named roles that are defined within different policy sets or different name spaces are treated as the same role.
If authorization policy is not attached to a given component and operation, the operation runs unprotected.
It is possible to create conflicts by specifying multiple policy sets in the @policySets attribute or by inheriting policy sets across elements. In this case, the following rules are used:
- The <denyAll> element takes precedence over <permitAll>, which takes precedence over <allow>.
- Roles from multiple <allow> elements are aggregated.
SCA authorization policy does not support authorizing users in foreign realms.
The OASIS SCA specification permits you to specify the authorization intent on the implementation. If the implementation contains an authorization intent, you must attach a policy set that satisfies the intent to the implementation. The attached policy set must contain the provides="authorization" statement in its definition.
In OASIS SCA, the security elements that a policy set can contain, such as authorization, securityIdentity, allow, and runAs, belong to the Tuscany namespace http://tuscany.apache.org/xmlns/sca/1.1.

Access to an SCA component is permitted or denied by using the following steps:

Procedure

The policy administrator creates one or more policy sets in the file named definitions.xml.

OSOA example

<definitions xmlns="https://www.osoa.org/xmlns/sca/1.0"
  targetNamespace="http://smallvilleBank"
  xmlns:sca="https://www.osoa.org/xmlns/sca/1.0">
  <policySet name="StaffAuthorizationPolicy"
 	appliesTo="sca:implementation.java"
 	xmlns="https://www.osoa.org/xmlns/sca/1.0">
    <authorization>
      <allow roles="staff"/>
    </authorization>
  </policySet>
  <policySet name="SupervisorAuthorizationPolicy"
 	appliesTo="sca:implementation.java"
 	xmlns="https://www.osoa.org/xmlns/sca/1.0">
    <authorization>
      <allow roles="supervisor manager specialist"/>
    </authorization>
    <securityIdentity>
      <runAs role="specialist"/>
    </securityIdentity>
 </policySet>
</definitions>

OASIS example

<definitions xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912"
  targetNamespace="http://smallvilleBank"
  xmlns:sca="http://docs.oasis-open.org/ns/opencsa/sca/200912"
  xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1">
  <policySet name="StaffAuthorizationPolicy"
       appliesTo="sca:implementation.java"
       provides="authorization">
    <tuscany:authorization>
       <tuscany:allow roles="staff"/>
    </tuscany:authorization>
  </policySet>
  <policySet name="SupervisorAuthorizationPolicy"
       appliesTo="sca:implementation.java">
    <tuscany:authorization>
       <tuscany:allow roles="supervisor manager specialist"/>
    </tuscany:authorization>
    <tuscany:securityIdentity>
       <tuscany:runAs role="specialist"/>
    </tuscany:securityIdentity>
  </policySet>
</definitions>

The assembler attaches the policy to the SCA composite.

OSOA example

<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="https://www.osoa.org/xmlns/sca/1.0"
  xmlns:bank="http://smallvilleBank"
  name="AccountServices">
  <component name="AccountAccess">
        <implementation.java class="smallvilleBank.AccountAccessImpl"
             policySets="bank:StaffAuthorizationPolicy"/>
  </component>
  <component name="AccountAudit">
        <implementation.java class="smallvilleBank.AccountAuditImpl"
             policySets="bank:SupervisorAuthorizationPolicy"/>
  </component>
</composite>

OASIS example

<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912"
  xmlns:bank="http://smallvilleBank"
  name="AccountServices">
  <component name="AccountAccess">
    <implementation.java class="smallvilleBank.AccountAccessImpl"
       requires="authorization" policySets="bank:StaffAuthorizationPolicy"/>
  </component>
  <component name="AccountAudit">
    <implementation.java class="smallvilleBank.AccountAuditImpl"
       policySets="bank:SupervisorAuthorizationPolicy"/>
  </component>
</composite>

The deployer assigns users and or groups to the roles that are defined in the composite.
The deployer assigns a user to the runAs roles that are defined in the composite.

What to do next

Access to the SCA component is permitted or denied according to the authorization policy.