Chapter 13. ActiveMatrix Policy Framework
Aspect-Oriented Design
Sometimes you need to introduce functionality into a process, but that functionality is not a fundamental part of the mainstream process. As an example, consider the Account Management Service from our earlier discussion of the ATM System architecture (Figure 13-1). To avoid unauthorized access to the service operations, you want to add some control over who is able to call them. In other words, you want to introduce a policy that governs access to the service. However, you’d like to accomplish this without modifying the basic design. Furthermore, you want to keep the concerns associated with access control separate from those of the core business processes. This is the idea behind aspect-oriented design.
Figure 13-1. Aspect from the Architecture Pattern Perspective
Aspect-Oriented Design1 is an emerging architectural philosophy that seeks to achieve this separation of concerns. Central to the discussion is the idea of a crosscutting concern. A concern is a matter of interest that applies in multiple situations in the core of the solution.2 The concern in this example is security, and the core is the architecture pattern.
The idea of crosscutting is that the concern needs to be addressed at multiple places in the architecture. In the example, access to each of the service operations needs to be governed. More broadly, access to other components (such as the Bank System) may need to be governed as well. Aspect-oriented design is applicable when there are crosscutting concerns.
Concerns are addressed by adding some behavior that addresses the concern to the design. This behavior, in aspect-oriented terminology, is referred to as advice. In the example, the advice is the access control policy that decides whether or not access should be granted. The encapsulation of the advice (added behavior) along with the specification of where it is to be triggered is referred to as an aspect. In the example, the indication that the access control policy needs to be applied to the interactions between the ATM Machine and the Account Management service defines the aspect.
If you examine the mapping of the withdraw cash process onto the architecture pattern shown in Figure 13-2, you can see that there are two aspects in this business process—two places at which access control policies need to be applied.
Figure 13-2. Aspects from the Mapping Perspective
The ActiveMatrix Policy Approach
The TIBCO ActiveMatrix® Service Bus provides a policy framework that marries the abstractions of aspect-oriented design with the implementation approach of the Service-Component Architecture (SCA) specification. In this framework, advice (added behavior) is specified in the form of policies. The aspect (specification of where the policy is to be applied) is accomplished by associating the policies with specific elements of the SCA design.
The policies and policy templates provided with ActiveMatrix Service Bus address a number of commonly encountered concerns, including:
• Security
• Transactional integrity
• Reliability
• Startup/shutdown sequencing
• Location independence
The remainder of this chapter provides an overview of this policy framework and the types of policies that are provided. Be prepared for getting into some details! Understanding how the policies tie in with the core application functionality requires getting under the covers a bit.
Policies and Policy Sets
Policy
The term policy, as used in the context of ActiveMatrix Service Bus, refers to a rule governing some aspect of application execution. One generally familiar usage of policies is to govern access to services by authenticating users and authorizing their use of the service. Less familiar might be policies that govern message delivery (at least once delivery, at most once delivery), and the start-up sequencing of components and the services upon which they depend.
Policy Sets
Each policy defines a single rule, but often it is necessary to combine two or more policies to describe the intended behavior. Such groupings are referred to as policy sets. A policy set can contain one or more policies. Policy sets are the primary artifacts used to administer policies in ActiveMatrix Service Bus.
Policy sets are defined by XML files. Some policy sets are predefined in ActiveMatrix Service Bus and are referred to as embedded policy sets. You cannot view the XML defining these policy sets. Other policy sets are defined by XML files that you provide. These are referred to as external (i.e., outside the ActiveMatrix Service Bus product) policy sets.
Policy sets can be applied to any SCA element: component, service, reference, or composite. We will see later how policy sets are associated with these elements.
The TIBCO ActiveMatrix Service Bus policy implementation conforms to the SCA Policy Framework V1.00.3
Table 13-1 lists the policy sets provided with the ActiveMatrix Service Bus product as of this writing.
Table 13-1. Policy Sets Provided with TIBCO ActiveMatrix Service Bus
Policy Set Templates
Many policies employ values that may need to change from application to application. For example, if you want to do role-based authorization, the list of roles authorized to access a particular service interface will vary from service to service.
To facilitate the use of such policies, ActiveMatrix Service Bus provides a number of policy set templates (referred to as simply policy templates in the product documentation) that contain placeholders for the values. To use these policy set templates, you edit the template XML file and save it. The edited file, with all values supplied, is a complete policy set that can be used as an external policy set. The default location (on Windows) for these templates is:
C:Program Files (x86)TIBCOamx-3amx3.0samplespolicysamples.zip
Consider the policy set in Listing 13-1. It contains one policy that defines authorization by role. The policy permits access to all operations when the role matches one of the entries in the role list. The template, as provided, has exactly one role: Manager. To use this template, you would replace Manager with a comma-separated list of the roles you want to allow, save this XML file under a new name, and later apply it in a project (this last part will be described later in this chapter).
Example 13-1. SamplesAuthorizationByRoleAllOperationsAllowedForRole.policysets
<sca:policySet
name="AuthorizationByRole_AllOperationsAllowedForRole.role"
provides="scaext:authorization.role"
appliesTo="webapp:implementation.web | soapbt:binding.soap.service">
<wsp:Policy template="tpt:AuthorizationByRole"
xmlns:tpt="http://xsd.tns.tibco.com/governance/policy/template/2009"
xmlns:xacml="urn:oasis:names:tc:xacml:2.0:policy:schema:os">
<!-- Authorize all operations for users with specific roles -->
<wsp:All>
<wsp:Policy>
<wsp:All>
<tpa:Authorization>
<tpa:ByRole>
<tpa:Default>
<xacml:Rule Effect="Permit" RuleId="">
<xacml:Description>All operations allowed for specific
Roles</xacml:Description>
<xacml:Condition>
<xacml:Apply FunctionId="is-in">
<!-- Replace the value "Manager" below with a
valid Role list. Role names are comma separated.
-->
<xacml:AttributeValue DataType="xsd:string">
Manager
</xacml:AttributeValue>
</xacml:Apply>
</xacml:Condition>
</xacml:Rule>
</tpa:Default>
</tpa:ByRole>
</tpa:Authorization>
</wsp:All>
</wsp:Policy>
</wsp:All>
</wsp:Policy>
</sca:policySet>
Some of the categories and templates provided with the Active-Matrix Service Bus include:
• Authentication: basic LDAP authentication; token-based LDAP authentication; SAML authentication (signed and unsigned)
• Authorization by Role:all operations allowed for role; authenticated users only; everyone allowed; nobody allowed; specific operation allowed for all roles; specific operation allowed for specific role
• Credential Mapping: fixed credential mapping; role-based credential mapping; SAML credential mapping signed; SAML credential mapping unsigned
• WSS Consumer: add username, token, timestamp, sign, and encrypt
• WSS Provider: authenticate username, SAML, token; decrypt
Policy Applicability
If you look over the types of policy sets and think about the different types of elements in an SCA design (components, services, references, and composites), it becomes obvious that certain types of policy sets only apply to certain types of elements. This concept is formalized in the @appliesTo attribute of an SCA policy set in which you can specify the type of element to which the policy set applies.
While you are unlikely to be creating policy sets from scratch (and therefore setting the values of @appliesTo attributes), the concept is still important. It allows you, for example, to associate multiple policy sets with a composite and have those policy sets automatically apply themselves to the appropriate elements within that composite.
Policy Enforcement Points
A policy enforcement point is, as the name implies, the place at which policies are actually enforced. The policy enforcement point in the TIBCO ActiveMatrix Service Bus is the node. Within each node we can be even more specific when it comes to access control policies. Referring back to Figure 9-6, every access to every implementation, binding, and communication resource can be governed by policies. This provides an extremely secure environment for computing and communications.
Associating Policy Sets with Design Elements
As of this writing, policy sets can only be associated with design elements at design time. In a future release, it is planned that policy sets may be associated at deployment time as well.
The mechanics of associating a policy set with a reference are illustrated in Figure 13-3. You select the reference, and in the Properties tab below select the Policies sub-tab. You select the Policy Sets icon, which becomes highlighted. At this point you can select Add a Policy Set.
Figure 13-3. Associating Policy Sets with a Reference at Design Time
Once you click on the Policy Set icon, the dialog shown in Figure 13-4 will appear. From this dialog you can either select an embedded policy set or reference an external policy set. You should consult the product manual for further information.
Figure 13-4. Selecting or Creating a Policy Set
Worth mentioning here is the fact that the external policy set you reference does not have to be in the project in which the composite is being defined: It can be in another project. This creates the opportunity to place policy sets in a project that is subsequently used (referenced) by a number of other projects. This can greatly simplify the creation and management of policies.
Policies That Access External Systems
Many policies require access to external systems such as LDAP. When this happens, the architecture pattern of Figure 13-5 must be employed. The actual access to the external system is managed by a special type of component known as a governance agent. When you create the governance agent (which will be described in a moment) you will give it a name, and it is this name that will appear in the policy set.
Figure 13-5. Architecture Pattern for Accessing External Systems
The governance agent, in turn, will require an ActiveMatrix Service Bus shared resource. This resource defines the configuration of the communications channel that will be used to communicate with the external system. When you configure the governance agent, you will have to provide the name of the shared resource that defines the communications channel.
Figure 13-6 shows the general procedure for accessing an external system from a policy set. At the time you are designing the solution requiring the policy set, you need to copy the template policy set into a project (remember, it doesn’t have to be the project containing the design) and edit the governance agent name that appears in the policy set. You’ll have to remember this name because you’ll need it later. Then you can reference the policy set from the design element to which it applies and generate the distributed application archive (DAA).
Figure 13-6. Procedure for Accessing External Systems in a Policy Set
In the administrator you need to create the shared resource template that defines the connection to the external system. The Active-Matrix Administrator provides dialogs for creating resource templates for all types of external systems referenced in the supplied policy sets. You create the shared resource template by selecting the template type and giving it a name.
Then you create the governance application from the template supplied by ActiveMatrix Service Bus. You name the governance application, taking care to use the same name that you put into the policy set. Next, configure the governance application to reference the shared resource you just created that defines the connection. Finally, you deploy the solution. You create an instance of the shared resource on the target node to which you will deploy the design element using the policy set. You deploy the governance application to the target node, configuring it to use the shared resource instance you just created. Finally, you deploy the design element using the policy set to the target node.
Table 13-2 lists the types of policies provided with ActiveMatrix Service Bus that require access to external systems and the corresponding shared resource templates that must be used.
Table 13-2. Policy Types Requiring Access to External Systems
An Example: Implementing a Policy Accessing LDAP
Let’s take a look at a concrete example in which you want to apply the BasicAuthenticationWithWebAppUsingLDAP.policysets.
The first thing to do is to make a copy of the policy set (which is really a template) and edit the governance application name (Listing 13-2). The listing shows this policy set highlighting the governance application name that is to be replaced. For our example, let’s call this the LDAP_Access_Application. Remember the name—you will need it later!
Example 13-2. BasicAuthenticationWithWebAppUsingLDAP.policysets
<?xml version="1.0" encoding="UTF-8"?>
<ep:policySetContainer
xmlns:ep="http://xsd.tns.tibco.com/amf/models/externalpolicy"
xmlns:sca="http://www.osoa.org/xmlns/sca/1.0"
xmlns:scaext="http://xsd.tns.tibco.com/amf/models/sca/extensions"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:tpa="http://xsd.tns.tibco.com/governance/policy/action/2009"
xmlns:tpc="http://xsd.tns.tibco.com/governance/policy/common/2009"
xmlns:jmsbt="http://xsd.tns.tibco.com/amf/models/sca/bindingtype/jms"
xmlns:soapbt="http://xsd.tns.tibco.com/amf/models/sca/binding/soap"
xmlns:webapp="http://xsd.tns.tibco.com/amf/models/sca/implementation
type/webapp"
xmlns:wssp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702
targetNamespace="http://www.example.com/policySets">
"
<sca:policySet name="BasicAuthenticationPolicySet"
appliesTo="soapbt:binding.soap.service.http|webapp:implementation.
web"
provides="scaext:clientAuthentication.basic">
<wsp:Policy template="tpt:BasicAuthentication"
xmlns:tpt="http://xsd.tns.tibco.com/governance/policy/template/
2009">
<wsp:All>
<wsp:Policy>
<wsp:All>
<tpa:AuthenticationByJaas>
<tpa:SecurityToken>
<tpa:ExactlyOne>
<!-- Enforce HTTP basic authentication -->
<wssp:HttpBasicAuthentication/>
</tpa:ExactlyOne>
</tpa:SecurityToken>
<!-- Replace the sample ResourceInstance attribute value
"DefaultLdapAsp" below with the name of a TIBCO
ActiveMatrix Governance Agent application that
references an "LDAP Authentication" resource instance.
-->
<tpa:SharedResourceLoginModule
ResourceInstance="DefaultLdapAsp"/>
</tpa:AuthenticationByJaas>
</wsp:All>
</wsp:Policy>
</wsp:All>
</wsp:Policy>
</sca:policySet>
</ep:policySetContainer>
There is an unfortunate terminology conflict in this file that may lead to confusion. The name of the element being edited is SharedResourceLoginModule, and the name of the attribute being edited is ResourceInstance. Despite these names, the value you are editing refers to the governance application, not the shared resource template that defines the connection to the external system.
After the policy set has been created, you can associate it with the service or composite you want it to govern. Note that if you associate the policy set with a composite, it will apply to all SOAP bindings and WebApp HTTP interfaces in that composite.
Over in the administrator you need to create the shared resource template that defines the connection to the LDAP server. The starting point for this is the Shared Objects menu on the administrator (Figure 13-7).
Figure 13-7. Starting Point for Defining the LDAP Shared Resource
This will bring up the Resource Templates dialog (Figure 13-8). If the resource template you are looking for (in this case the LDAP Connection) is not in the list, click on the +New icon.
Figure 13-8. Resource Templates Dialog
This will bring up the Add Resource Template dialog (Figure 13-9). Select the LDAP Connection in the Type pull-down and enter a name for the resource template. Here we have given it the name LDAP_Connection_A. Set the parameters appropriately and click Save.
Figure 13-9. Add Resource Template Dialog
Next, you need to create the governance application that will manage the interactions with the LDAP server. In the administrator, click on Applications on the menu bar and then +New. This will bring up the dialog of Figure 13-10. Enter LDAP_Access_Application, the application name that you put in the policy set earlier. Make sure the An existing application template button is selected and click Next.
Figure 13-10. Creating the LDAP_Access_Application
This will bring up the dialog in Figure 13-11. Scroll down and select the LDAP authentication governance agent and select Next.
Figure 13-11. Selecting the LDAP Governance Application Template
On the following dialog, select Done with Application Setup. From this point on, the remainder of the procedure is the same as for any other application being deployed: Create the needed shared resource on the target node; deploy the governance agent to the node, configuring it to use the shared resource; and deploy the solution elements requiring the governance agent.
Policy Intents
Policy intents are used to describe the abstract policy requirements of a component or the requirements of interactions among components represented by services and references.4 An intent expresses a need that eventually must be satisfied by a policy set.
ActiveMatrix Service Bus defines policy intents in a number of categories, including:
• Security: client and server authentication; authorization; credential mapping; provider and consumer confidentiality (encryption); provider and consumer integrity (signing)
• Transactions: managed transactions (requires an open transaction); transacted one-way (messages are sent within a transaction and delivered only after the transaction commits)
• Virtualization: secure virtualization (references and services use SSL for communications)
• Reliability: at least once message delivery; at most once message delivery
• LifeCycle: start services first (referenced services must start before the referencing component starts); prepare before un-deploy (component confirms readiness to un-deploy to administrator)
Policy intents are associated with SCA elements at design time (Figure 13-3). Each policy intent has a unique identifier, such as scaext:clientAuthentication.basic.
A policy intent is satisfied by associating a policy set that satisfies the intent with the same element with which the intent is associated. Each policy set has a provides attribute that lists the intents satisfied by the policy set. For example, if you look at Listing 13-2 you will see the provides attribute has the value scaext:clientAuthentication.basic.
A policy intent must be satisfied before deployment can complete. As of this writing, the policies that satisfy the intents must be provided at design time. It is intended that in a later ActiveMatrix release the actual association of the policy sets will be possible at deployment time.
Summary
A policy is a rule that governs some aspect of run-time behavior. Policy sets are groups of policies and are the atomic unit of policy administration. Some policy sets are built into the TIBCO ActiveMatrix Service Bus and are referred to as embedded policy sets. Other policy sets are defined by XML files and are referred to as external policy sets. These external policy sets are resources that can be referenced across ActiveMatrix projects.
A policy set template (or simply policy template) is a policy set that requires editing before it can be applied. These edits typically involve supplying values of various types. The resulting edited policy set can then be used as an external policy set in an ActiveMatrix project.
Different policy sets are appropriate for different kinds of design elements. Each policy set declares the type of design element to which it applies. These declarations enable policy sets to be applied to complex elements such as composites and automatically determine the sub-elements to which they apply.
Policies are enforced in ActiveMatrix nodes. Within each node, each component, service, reference, and communication resource has an associated logical policy enforcement point at which access control and communications policies will be enforced.
Policy sets are associated with design elements: components, services, references, and composites. At present, this association is done at design time. In future releases, it will become possible to associate policy sets at deployment time.
Policies that access external systems such as LDAP require special ActiveMatrix Service Bus components, known as governance applications, to mediate the external system interactions. The connection details are specified in a shared resource template. When the design element associated with the policy is deployed, the governance application and shared resource must also be deployed on the same node.
Policy intents are requirement statements about policies that are needed. Each policy intent has a unique identifier, and each policy set lists the intents that it will satisfy. Policy intents are associated with design elements at design time. At present, the corresponding policy sets must also be provided at design time, but in later releases it will become possible to defer the provisioning of the policy sets until deployment time.