Policy Manager Demo With BW

8/6/2019 Policy Manager Demo With BW

1/16

Policy Manager Demo 1.0

There are a number of policy manager demos floating around that show how to apply policies against

services deployed in the grid. This demo addresses BusinessWorks services that are deployed in the

TRA. The reason for this demo is that increasingly we are getting requests from existing BW customers

about applying policies against existing BW services.

Overview

Scenario

FrozenHiker.com is an outfitter for people interested in outdoor activities. To increase business, they

have offered up a service that provides information on area hiking trails. The service provides two

operations:

1. Lookup - anyone who is registered with FrozenHiker.com can use this service to look-up trailconditions. The service returns the general condition, and some notes. Only registered users

who have purchased a membership can see the notes.

2. Update - this operation allows rangers to update trail conditions. Only rangers are allowed tocall this operation.

Environment

The following TIBCO products need to be installed and running:

1. ActiveMatrix Administrator2. BusinessWorks3. PolicyManager4. PolicyAgent5. Designer

The following auxiliary products need to be installed and running:

1. SQLServer Database - contains the trail data2. OpenLDAP - contains membership data


2/16

BusinessWorks Project

The BW project contains two processes that implement the operations described in the scenario:

There is nothing associated with these services related

to policy enforcement. This service gets deployed using

the TIBCO Administrator. This should be deployed prior to running the demonstration.

Start-up

The following steps are required to run the demo:

1. Ensure that SQLServer is running2. Ensure that OpenLDAP is running3. Ensure that EMS is running4. Start the TIBCO Management Daemon5. Start HSQLDB database6. Start the AMX Admin Server7. Start the TrailConditions Service in the TIBCO Administrator8. Start PolicyManager9. Start the PolicyAgent10.Start Designer11.Access the ActiveMatrix Administrator


3/16

Demonstration Script

You can begin with either a power point or white board session to discuss the mechanics of Policy

Manager. I prefer to use the white board because I think it adds some credibility.

PolicyManager Overview

Today, organizations face a number of challenges both internally and externally when it comes to

system and service access, auditing, logging, etc. Some of these pressures are regulatory in nature,

whilst others are based on internal requirements. Traditionally, policies have needed to be "coded into"

the service or application.

The challenge becomes, every time a new policy needs to be added, or an

existing policy needs to be updated, the code needs to be modified, tested,

and the service requires redeployment. This is expensive in terms of labor

hours, as well as time to deploy.

Another issue is that the developers now understand all of the nuances

associated with the policy, and potentially how to circumvent the policies.

Ideally, we would want to be able to manage and apply the policies

separately from the service itself. This would give a lifecycle flow similar to the following:

In order to support this type of approach, PolicyManager makes use of policy agents. There are two

types embedded and proxy. Embedded agents reside within the hosting framework of the service. For

example, we provide embedded agents for ActiveMatrix ServiceGrid, IBM WebSphere, and Microsoft

Interface

Policies

Logic


4/16

.net. The advantage of an embedded agent is that it eliminates additional routing and potentially

network hops.

Sometimes there is a need to use the proxy approach. This could be due to services that are deployed

outside of the environments identified above. This demonstration is going to focus on the proxy agent

approach using a BusinessWorks service that is deployed in the traditional TRA environment. While theproxy agent can be deployed on the same server or a separate server for our demonstration they will be

co-located on the same server.

The question now becomes, how do we get the policies to the agent? In order to understand this, we

need to look at mechanisms for creating and deploying policies. We begin by accessing the policy

template library looking for a suitable template. Out of the box, TIBCO provides templates for the

following:

1. Authentication2. Authorization3. Logging4. Encryption5. Censor Response6. Routing

Many of these have several different variants to meet individual needs. There is also the capability to

build custom policy templates if needed.

Within the administration UI, policies are configured by supplying information required by the template,

and then applying the resulting policy to one or more services. This process will be demonstrated as

part of the live demo. When the policies are applied, they are pushed to the appropriate agents.


5/16

Live DemoFor this demonstration we have a fictitious retailer/outfitter that caters to the outdoors types. In the

interest of promoting their business, gaining customer information, and increasing web traffic, they

started offering a service where registered users could access information on hiking trail conditions. Any

registered user can see the general condition of the trail (good, fair, poor, etc). Members who pay a

premium can also receive detailed notes. In order to control the accuracy of the data, only rangers are

allowed to update the conditions.

We begin with a couple of simple services, that we created in BusinessWorks:

Looking at the TIBCO Designer, we see one service with two operations. Notice that there is nothing

associated with these services related to policy enforcement. The developer simply created a service to

provide the requested functions. This service is then deployed using the TIBCO Administrator:


6/16

Users are managed using an LDAP server. In this case I am using OpenLDAP.

[At this point, you may want to show the different roles and the associated membership]


7/16

PolicyManager UI

Let's begin by looking at the administration UI for policy management. When we access the UI, we

receive a summary of our policy management environment:

In this case, I see that there are 4 managed services, of which two are running. I can also see that there

are a total of 9 applied policies, and that there are 12 other system services running. Let's look to see

what we have for managed services. By selecting the Services tab, I can see what the managed services

are, what policies are applied to each service, and if the service is running:

Services deployed within the ServiceGrid are discovered automatically. If we want to apply policies to a

service that require a proxy we need to discover those services. For TIBCO BW services deployed in the

TRA, there are two options. There is autility that will register all services in a domain with thePolicyManager, or we can register the service by selecting the Register button, and providing the WSDL

as follows:


8/16

Since I already have my service registered, I will cancel out and go to that service.

Notice that I have 4 policies applied against this service. How were these policies created and applied.

Let's begin by looking at the Policy Templates tab:

Here I see all of the templates that are available to me for creating policies. To create a policy I select

the edit button associated with the policy, and add policy from the pop-up menu:


9/16

In this case I selected the Authorization, Classification by role policy template. I can identify roles,

operations and services. Let's look at one that is already configured.

Selecting the Policies tab, I am presented with a list of policies that are currently configured. If we select

the authorization policy, we see the following:

A couple of things to point out here. Notice that I set a default authorization role. In this case, I chose

to restrict operations to only rangers as my default. I could have taken the opposite approach with

having the default be more open. It depends upon your requirements, and how you prefer to do things.


10/16

For Lookup operations, I loosen things up and allow ValidIDs access. I can select the role by selecting the

drop-down, this provides a list of the roles that I have available to me. Remember that we had an

additional requirement whereby we only wanted to provide detailed notes to paid members? This we

handle using a censor response policy. Let's exit here and look at that policy.

Here I identify the conditions to apply the censoring. In this case I selected to censor for anyone not a

member of members. I could have also censored anonymous users, or everybody. I then provide my

XSLT to define the censoring. In this case, I am replacing the contents to the notes tag with the message

you must be an approved member to view the notes.

Now it is time to see this in operation. Clicking the apply button deploys the policy to the appropriate

agent. Before we switch back to Designer, let's look at one last thing. If I go back to the Services Tab

and select the structure tab for my service, I can see that it is managed by proxy:


11/16

If I select the proxy icon, it shows me the link for the wsdl that needs to be used by clients:

Running the Test Cases

Looking back at Designer, we have some test processes that call our service. The DT processes use the

identity of a ranger to access the service operations, the AK processes use the identity of a paid

member, and the JH processes use the identity of a registered user who is not a paid member. For our

ranger, both operations will succeed, for the paid member, only the lookup operation will succeed.


12/16

Within BW, we need to establish identities that will get passed with the SOAP request. For example if

we look at the DTIdentity, we see that we provide a userid and password:

Within the SOAP Request/Reply Activity in process, we associate the identity with the call:

As you can see, we have 5 test processes, 2 using the DTIdentity which reflect the ranger role, 2 using

the AKIdentity which reflect the paid member role, and 1 using the JHIdentity which reflects a valid user

role. When we run the tests we observe the following behavior:

Notice that 4 of the tests

pass and one of them failed.

If we examine the results of

the tests, we see that the

DT tests returned

successful. This is expected

since the DT tests provided

the credentials for a ranger.

Looking at the output from

the SOAP Request Reply

activity reveal the following:


13/16


14/16

Looking at the AK tests, we see the output for the lookup matches that of the DT tests, but the output

for the update indicates that access was denied:


15/16

Our final test, shows a successful response, but when we examine the output we see that the Notes

have been censored since the JK user is not a paid member:

Conclusion

PolicyManager provides a powerful and flexible tool for companies to leverage in order to create, apply,

and manage policies against services.


16/16

Appendix A - Installing and configuring OpenLDAP

One of the components required for this demonstration is an LDAP server. I chose to use OpenLDAP,

but any LDAP server should work. To get OpenLDAP for windows go to:

http://www.userbooster.de/en/download/openldap-for-windows.aspx

Once on the site, download the openldap-for-windows.msi, and run the program.

Be sure to note the port that is assigned. The default forLDAP is 389, but if you already have something

using that port it will select a different value. Now that theLDPA server is installed, verify that it is

running by examining your windows services.

Next you will need to download a client to use to configure OpenLDAP. I use JXplorer, which can be

obtained at http://JXplorer.org.

Documents

Policy Manager Demo With BW