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.
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.
- 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.
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.
<definitions xmlns="http://www.osoa.org/xmlns/sca/1.0"
targetNamespace="http://smallvilleBank"
xmlns:sca="http://www.osoa.org/xmlns/sca/1.0">
<policySet name="StaffAuthorizationPolicy"
appliesTo="sca:implementation.java"
xmlns="http://www.osoa.org/xmlns/sca/1.0">
<authorization>
<allow roles="staff"/>
</authorization>
</policySet>
<policySet name="SupervisorAuthorizationPolicy"
appliesTo="sca:implementation.java"
xmlns="http://www.osoa.org/xmlns/sca/1.0">
<authorization>
<allow roles="supervisor manager specialist"/>
</authorization>
<securityIdentity>
<runAs role="specialist"/>
</securityIdentity>
</policySet>
</definitions>
- The assembler attaches the policy to the SCA composite.
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://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>
- 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.