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
Note: 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 as shown in the following
example:
<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
as in the following example:
<?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.