6.0_PM_Training_Core_V1.1 (1).pdf

8/12/2019 6.0_PM_Training_Core_V1.1 (1).pdf

http://slidepdf.com/reader/full/60pmtrainingcorev11-1pdf 1/231

Policy Manager TM 6.0

Copyright © 2010 SOA Software, Inc. All Rights Reserved. Specifications Subject to Change W ithout Notice. Slide 1

Core Concepts



May 2011 V1.0 Copyright © 2010 SOA Software, Inc. All Rights Reserved. Specifications Subject to Change Without Notice. Slide 2

Core Concepts Agenda

Day 1

SOA Software Introduction

• Features Overview

• Policy Manager Installation– Admin console

– Configuring Policy Manager

• The Policy Manager Management Console

Managing the Runtime Environment

• Installing and Configuring Network Director

• Registering Services in Policy Manager

• Policy Manager Operational Policies

• Integration with Third Party Identity Systems

• Contract Definition and Configuration




Core Concepts Agenda

Day 2

Managing the Runtime Environment (continued)• Quality of Service (QoS) Policies

Configuring Role Based Access in Policy Manager

• Object Based Security in the Policy Manager Console

Monitoring and Auditing Capabilities in Policy Manager

• Real-time Data

• Usage Data

• Historical Data

• Audit Data

Policy Manager Migration

Troubleshooting Tips

Support




Why SOA Policy Manager?

• In a traditional implementation theinteraction is as follows:

– Client invokes service directly

– Hard-coded service location

– No, or hard-coded, security

– No routing, failover, or load-

balancing– No performance or availability

monitoring

– No SLAs

Client/Application

Web/Rest Service




Policy Manager Benefits

• Policy Manager and its features allow you to govern, monitor, manage and secure

the SOA infrastructure.





Features Overview


http://slidepdf.com/reader/full/60pmtrainingcorev11-1pdf 7/231May 2011 V1.0 Copyright © 2010 SOA Software, Inc. All Rights Reserved. Specifications Subject to Change Without Notice. Slide 7

The SOA Container

• Policy Manager and all of its components are OSGI enabled, allowing them to

deployed in an OSGI container.

• An SOA Container allows for various OSGI feature bundles to be deployed into it.

• The SOA container is a single java process running on a specified port.

• The SOA Container is managed using a web browser to access the container

Admin Console

SOA Container

Feature Bundles

Feature Bundle #1

Feature Bundle #2

Port 9900

Admin Console





Policy Manager Feature Bundles

August 2010



Policy Manager Deployment

• The first set of features required in a Policy Manager deployment are the PolicyManager Service and Policy Manager console.

• The Policy Manager is comprised of a set of applications that provide all theruntime policy enforcement, management, security, service configuration andruntime governance. The Policy Manager console is provides the a user interfaceto manage and configure the runtime components.

• The Policy Manager runs on a single machine and requires a connection to adatabase.

Database



Policy Manager Services: Feature Bundle

• The Policy Manager Services and Console bundles are required for a PolicyManager installation.

• The Policy Manager Service Feature bundle is comprised of a number ofapplications that include:

– Security Application

• Provides authentication implementation

• Rule based authorization implementation

• Authentication service that validates security tokens andmaps tokens to identities

• Integration with 3rd party identity stores

– Alerting Application

• Provides management of alerts generated within the SOA

• Redistributes events using SNMP, email or through custom scripts

– Management Application

• Gathers metrics about services and contracts• Gathers audit trail data about individual message exchanges

• Provides metrics for reporting purposes (real-time and historical)

• Provides QoS/SLA threshold monitoring

– Registry/Repository Application

• Provides complete UDDI v2 and V3 interface to services and organizations defined

• Provide REST based interface to retrieve WSDL documents with embedded WS-Policy elements

SOA Container

Policy Manager

Services

Policy ManagerConsole

Port 9900



SOA Container

Policy Manager Console Feature Bundle: SOA Governance

• The Policy Manager Console bundle is required to run the Policy Manager web-

based console.• The console run in the same container as the Policy Manager Services or in a

separate container.

• The Policy Manager console features include:– Accessed through a browser (Firefox, Internet Explorer)

– Customer definable hierarchy for organization and security

– Full Role Based Access Control support– Policy Management: Operational, Compliance, QoS (Quality of Service)

– Configure/Manage services, contracts, policies, metadata

– Customizable workflow and lifecycle management ofservices, contracts and policies

– Full monitoring capabilities

– Virtualization (mediation) of services SOA Container

Policy ManagerServices


Port 9900

SOA Container



Port 9900

Port 80



Policy Manager Network Director

The Network Director provides:

• Service Virtualization.

• Protocol/Message Mediation.

• Virtual services capabilities

– Consist of operations from multipleservices (aggregate virtual service)

– Enforces Security and Messaging Policies

– Provide load balancing

– Provide fault tolerance

• Policy discovery required for policyenforcement from the Policy Manager.Database

Endpoint Services

Application/Consumer

9905

SOA Container

Network DirectorFeature



Policy Manager Cluster Support Feature

• Allows propagation of configuration changes made to the container.

• Configure a “master” Policy Manager and propagate configuration changes to the “slave” nodes.

Database

MasterPolicy Manager

Node

Slave

Policy ManagerNodes

Configuration changes madeat the Master Node propagatedto the Slave Nodes.

SOA Container



Port 9900

Cluster Feature



Policy Manager Delegate

• The Delegate (a native client-sidedelegate) intermediary provides

abstraction from:– Security Policies

– Messaging Policies

– Transports

– Endpoint Locations

• It discovers the policies it needs to enforcefrom the central Policy Manager

• It reports performance informationaccording to its policies to Policy Manager



SOA Software Tomcat Agent

• The Agent (a native in-container agent)intermediary provides last mile policy

enforcement– Security

• Authentication

• Authorization

• Auditing

• Privacy

• Non-repudiation

– Monitoring

• Performance• Availability

• Throughput

• It discovers the policies it needs to enforcefrom the central Policy Manager

• It reports performance informationaccording to its policies to Policy Manager



SOA Software Ping Support

• Adds ping support to any of the SOA Software containers to allow verification thatthe container is up and running.

• HTTP GET and HTTP HEAD supported

• The ping request returns TRUE it the container is running

• The who request returns the container key

http://<instance_host>:<instance_port>/pingrest/pinghttp://<instance_host>:<instance_port>/pingrest/who

ResponseReceived

True<container key>



The Policy Manager Deployment

• Policy Manager feature bundles can be deployed together in a single container orseparately in multiple containers.

• Policy Manager feature bundles can be deployed in a standalone container or inany J2EE container.

Database Database

Application ServerStandalone Container



Policy Manager Embedded Agents

• Deployed within the Application Server

• Intercepts requests for services deployed in the Application Server• Optionally discovers and/or manages services deployed in the application

server

• Enforces policy defined in the Policy Manager (Management Policy,Service Level Policies) for the services being managed by the Agent

• Agents are specific to the application server (and downloaded separately)

EmbeddedAgent

Service

Application Server

Database

NetworkDirector

Application/Consumer





Installation



Policy Manager Installation – Pre - Requisites

• The following pre-requisites are required prior to installing and configuring thePolicy Manager:

– Supported Database: Oracle, SQL Server, MySQL, or DB2

– Database Details (port, instance, username/passwords)

– Database user must have the rights to create tables and update the schema

Note: Database scripts are provided to manually create the Policy Manager database ifrequired.

– The Policy Manager instance does not require admin/root privileges to the operatingsystem. The Policy Manager user must just be able to read/write to its directorystructure.



Installation/Configuration Checklist

Install (setup file)

• Install the Policy Manager Software

Configure Policy Manager Instance (Configurator)

• Create a container for the Policy Manager instance

• Configure the Policy Manager Instance (port, admin user)

Configure Policy Manager (Admin Console – web based console)

• Install the required Policy Manager Feature Bundles from the Admin Console of

the Policy Manager instance

• Log into the Policy Manager Console



Policy Manager Installation

The Policy Manager can be installed as a standalone container or in any J2EE container.

• Download the Policy Manager binary from the Support Site.

• Run the setup on Windows:

>PMSM-Windows-6.0.0.exe

• Run the setup on UNIX systems it use the X-Windows or use the following command to runthe setup from the command line:

$ ./PMSM-Linux-6.0.0.bin -i console

• The Policy Manager software default installation directory is: <install_directory>/sm60




Policy Manager Directory Structure Overview

• The Policy Manager installation creates the following directory structure in the<install_directory>/sm60 subdirectory:

– ./bin Contains all the Policy Manager executables and batch/shell script files

– ./config Configuration files for the system. Workflow definition templates.

– ./dbscripts Database scripts used to create the Policy Manager database and schema. Can be usedby the DBA to create/load the database/schema if required.

– ./docs Help documentation.

– ./jre The Policy Manager JRE.

– ./keystore The java keystore that can be loaded into the Policy Manager.




Policy Manager Directory Structure Overview - Continued

– ./lib Policy Manager bundles

– ./license Policy Manager third party license files

– ./mib The Service Manager MIB

– ./schemas Policy Manager schema files




Policy Manager Directory Structure - ./instances

• The instances directory contains the configuration and log files for each containerinstance that is configured. The contents of this directory is as follows:

• ./instances /configurator

Configurator program to create new instances

/<instance_name>A directory is created for each instance that is configured

/cacheInstance cache

/deployInstance configuration files

/logInstance log file




Configure a Policy Manager Instance

• The Policy Manager instance is created though the use of the Policy ManagerConfigurator. This can be invoked from either a wizard or through the commandline.

• The Configurator creates the SOA container that allows features to be deployedinto it (i.e. Policy Manager, Network Director etc.).

• To start the configurator wizard (requires X-Windows library if running on UNIX

systems) use the following command:

$./sm60/bin/startup.sh (.bat) configurator

• The Configurator Wizard:

– Creates the Policy Manager instance

– Defines the port number for the instance– Creates the Policy Manager instance directory structure

– Defines the Administrator username and password to access the Admin console

– Allows selection of the deployment option (Standalone container or within a Container)

– Defines the startup options for the container (Standalone, Windows Service, Do not start)

After the configuration is complete, the Policy Manager Admin Console is started.




• The Policy Manager configurator can be run from the command line. A propertyfile is required that contains the details for the instance being created:

deployment=Standalone Deployment

# valid values are ‘Standalone Deployment ‘ and ‘Tomcat Deployment’

container.instance.name=pm60

credential.username = administrator

credential.password = password

default.host=10.1.22.139

default.port=9900

# Uncomment to install the Policy Manager as a Windows Service

# Windows.service=true

#Tomcat specific (for deployment=Tomcat Deployment)

# tomcat.root.dir= C\:/tomcat 6.0

# tomcat.context.path=/soa

# tomcat.application.base= C\:/tomcat 6.0\webapps

• To run the configurator use the following command:

$ ./sm60/bin/startup.sh/.bat configurator –Dsilent=true –Dproperties=<path_to_property file>

Creating the Policy Manager Instance – Command Line





The Admin Console

August 2010




Configure the Policy Manager: Admin Console

• After the Policy Manager instance is created, the web-based Admin Console for isrequired to install the Policy Manager features, configure various container properties,

add additional repositories to the container and view the status of the container.

• The Admin console is included in the SOA container by default and starts on the portthat was specified during the configuration of the instance.

• To start the Admin Console:

$./sm60/bin/startup.sh (.bat) <instance_name>

Example:$./startup.sh/.bat pm60

• The Admin Console is accessed from the following URL:

http://<PM_host>:<PM_Port>/admin /

• The administrator username and password are required to log into the Admin Console.




The Admin Console

• The SOA Admin console is required to install/uninstall feature bundles, apply updates, modifythe configuration parameters, view the status of the System and restart the container.

• The Policy Manager Console and Policy Manager Service features are required for the PolicyManager instance.




The SOA Admin Console: Installed Features

• If there are any incomplete tasks associated with the features that have beeninstalled they are displayed in the Installed Features tab.




SOA Admin Console: Configuration

• The Admin Console Configuration tab is used to modify any of the installedfeature configuration parameters such as add a new database, manage the PKIkeys for the instance, modify container timeouts, change log levels and modifythe administrator password.

• Most of the changes are made dynamically and do not require a container restart.




SOA Admin Console: Repository

• Updates are installed from the Admin Console Repository Tab. Updates can beinstalled from the local repository or from the remote SOA Software repository.

• To connect to the SOA Software repository, you must have a logon to the SOASoftware Support Site.




SOA Admin Console: System

• The Admin Console System Tab displays the status of the instance and thesystem on which the instance is running.

• The Admin Console also allows a remote restart of the container instance.




Configuring the Policy Manager

• After the Policy Manager features have been installed in the Policy Managerinstance, additional steps/tasks are required to complete the Policy Manager

configuration.

• The configuration wizard in the Admin console steps through the following tasks:

– Create a Certificate for the Policy Manager (and load it into the Policy Manager TrustedCertificate store)

– Create the Policy Manager Database and load the schema and data

– Restart the framework

– Log into the Policy Manager Web-based Management Console




Generate a Certificate for the Policy Manager

• The configuration process requires the generation of a certificate for the PolicyManager. This certificate is loaded into the Policy Manager Trusted CA store.




Configure the Database Information

• A database is required for the Policy Manager. Supported database include: MySQL, SQLserver, Oracle and DB2. The JDBC database drivers are required for all databases with the

exception of Microsoft SQL Server.• Database scripts are optionally available to create the Policy Manager database and load the

schema/data manually.

This is the PolicyManager databasethat is created andthe PM user that willaccess the database.

Database Admin Userand Password




Load the Schema and Data

• The Configurator creates the database, loads the schema and data and restartsthe Policy Manager Framework. Once restarted, the Policy Manager Management

Console can be accessed.

Creating the database

Restarting the Policy Manage Instance




Starting the Policy Manager

The Policy Manager is started using the following methods:

• From the Command Line>startup.sh <instance_name>

>startup.bat <instance_name>

Example:>startup.sh pm60 -bg Starts the instance in the background

• Windows Service>registerPMService.bat <instance_name>

Example:

>registerPMService.bat pm60

• From the Admin Console – System Tab




Training Use Case: Policy Manager Installation

• Install Policy Manager and create an instance that runs on Port 9900 (DefaultPort).

• Add the Policy Manager Console and the Policy Manager Service features into thecontainer.

• Configure the Policy Manager features and create the Policy Manager database.

• Access the Policy Manager Console from a browser.





The Policy Manager Consoles




Policy Manager Admin Console

• There are two consoles that are used for the Policy Manager:

• The Admin Console

– Used to manage the container instance

• Add/delete features

• Configure container properties

• View the status of the container

– Accessed from a browser using the following URL:http(s)://<container_host>:<container_port>/admin/




The Policy Manager Console

• The Policy Manager Console

– Used to configure/govern the Policy Manager runtime environment

• Register services, contracts, containers

• Create policies (i.e. operational, SLA, compliance)

• Monitor activity

– Accessed from a browser using the following URL:http(s)://<PolicyManager_host>:<PolicyManager_port>





The Policy Manager Console

Configure/Govern the Runtime Environment




Policy Manager Console Overview

• All runtime governance, configuration, monitoring and policy configuration is donefrom the Policy Manager Console Workbench Tab.

• Access the console using the following URL:

http://<pm_host>:<pm_port>/

2. The Main Tabs are used toconfigure and monitor allPolicy Manager functionality

1. Organizational Treedisplays configuredhierarchy and allowscategorization,access control ofservices, policies,containers andcontracts

3. Actions portlet displaysthe actions available forthe object selected in theOrganization Tree

4. Workflow Task portletdisplays the workflow tasksor actions for the userlogged into the PolicyManager Console




Alerts Tab

• Displays the alerts for all the components in the Policy Manager installation(includes summary and detailed information)

• Allows the addition and modification of alert codes

• Enables the configuration of alert “actions” including:

– Invocation of a Management Script.

– Forwarding of alerts to SNMP host(s).

– Forwarding alert notification to email groups.




Security Tab

• Define users, consumer identities and/or groups in the Policy Manager LocalDomain (database).

• Configure PKI keys for Local Users or Users that reside in an External Domain (i.e.LDAP directory, Active Directory).




Auditing Tab

• Audit data displays all Alert and System configuration changes made to the PolicyManager.

• All logins and any configuration modifications (add, deletes and modifications) arelogged in the Audit Trails.




Configure Tab - Registry

• Requires System Administrator privileges to add to the Registry.

• Configure the Registry, configure workflow, manage certificates, create externalidentity systems and configure system email for certificate expiration.




Configure Tab - Workflow

• Allows configuration of customizable service and contract workflow.

• Workflow can optionally be disabled.




Configure Tab - Security

• Configure Policy Manager as a Certificate Authority

• Management of PKI Keys

• Creation of external Identity Systems

• Creation of Identity Profiles




Configure Tab – Email

• Configures Policy Manager to send email notification for certificate expiration.





Policy Manager Console

The Organizational Tree

August 2010

Policy Manager Workbench Tab




Policy Manager Workbench Tab

Organizational Tree Summary

Four folders are created by default under eachorganization.

• ServicesServices defined in the organization

• ContractsDefine the service consumption relationship between theconsuming and providing organizations.- What services can be consumed- What users/applications are allowed to consume the

services

• PoliciesDefines the Policies (Operational, Compliance and/orQOS) that are available to the organization and can beassigned to the respective organizational objects.

• ContainersNetwork Director and/or Agent containers defined in theorganization.

There are two default organizations created under theRegistry organization after installation.

• Discovered Services Used when migrating between different Policy Managerversions.

• SOA Software Policy ManagerContains the Policy Manager services and containerinformation.

Th SOA S ft P li M O i ti




The SOA Software Policy Manager Organization

• The SOA Software PolicyManager Services subtree

displays all the services thatare exposed and used by thePolicy Manager. Theseservices can be used toinvoke Policy Manageroperations.

• The Policies subtree displaysthe policies that are requiredto invoke the Policy Managerservices.

• The Containers subtreedisplays the Policy Managercontainer details includingthe port number(s), thetransport listeners (http/s,JMS), access points andother configurationinformation pertaining to thecontainer.

“S b” T b




“Sub”-Tabs

• Sub-tabs display the options available for the objects chosen in the PolicyManager Organization Tree.

• The Details sub-tab provides a summary of the selected object.

Sub-Tabs

O i ti C t t S b T b




Organization: Contacts Sub-Tab

• The Contacts sub-tab provides contact information for the organization includingemail addresses, phone numbers and postal address.

• The Contacts created can be used in the workflow process to generate emailnotifications during specific states in the workflow process.

O i ti Id tifi S b T b




Organization: Identifiers Sub-Tab

• Displays identifiers assigned to the organization.

• Identifiers facilitate searching.

Organization: Categories Sub Tab




Organization: Categories Sub-Tab

• UDDI categories assigned and/or created for the organization.

• Categories facilitate searching.

Organization: Monitoring Sub Tab




Organization: Monitoring Sub-Tab

• Provides Monitoring data for all services in the organization.

• Monitoring data displayed for the organization includes: alerts, service logs and

historical data.



Organization: Security Sub Tab




Organization: Security Sub-Tab

• The Security sub-tab is used to assign users to roles defined for the organizationtree.

• The roles define the access users/groups have to specific objects in the PolicyManager.

• The roles define the privileges users and/or groups have to Policy Managerobjects in the selected organization (Services, Contracts, Policies, Containers).

Policy Manager Search Capabilities




Policy Manager Search Capabilities

• Policy Manager provides extensive service search capabilities through the use ofthe Search filter.

• Multiple criteria rules are supported.

• Searches can be saved and re-used.





Create an Organizational Hierarchy

August 2010

Creating an Organizational Hierarchy




Creating an Organizational Hierarchy

• Before objects are added to Policy Manageran Organizational hierarchy should bedefined.

• Each organization created is categorizedas a: Application, Company, Department,Partner or Project. Note: These are thedefault categories. Additional categoriescan be added as required.

• The organizational lay out is based oncustomer needs, security requirements andworkflow processing that drives thedeployment of services in these organizations.

• Each organization created is assigned a uniqueUDDI key that is manually entered orgenerated automatically. This key is required.

Mapping Policy Manager Runtime Components to




Policy Manager Console Objects

• Policy Manager Console objects in the Organization Tree map to the Policy Manager runtime(features) components configured.

End User/ApplicationBusiness Partner

NetworkDirector/Agents

Service

Provider

Runtime

Defines relationshipbetween the ProviderAnd the Consumer

Policy Manager – The Benefits




Policy Manager The Benefits

• Policy Manager provides a user friendly web-based interface to configure,manage, and monitor the Policy Manager deployment.

• Policy Manager provides the developer access to all relevant service artifactsincluding WSDL Documents, Message schema, Requirements and Designdocuments.

• Policy Manager is used to manage/track all stages of the service lifecycle, from

inception to deployment into production through both contract and serviceworkflow .

• Policy Manager provides Object Based Security to control access to the Services,Contracts, Containers and Policies defined in the Organizational hierarchy.

Policy Manager = Operational Governance

Training Use Case




Training Use Case

The following use case will be configured and used throughout this training course:

• There is a top level company organization that resides under the Registry Node inPolicy Manager.

• Under the company organization, two sub organizations exist:

– Engineering: This is the Provider Organization and where all the services will beregistered

– QA: This is the organization that where the consuming identities will reside. Theseidentities will consume the services provided by the Engineering organization.





Installing and Configuring

Network Director (ND)

Network Director – Runtime Policy Enforcement




Network Director Runtime Policy Enforcement

• Network Director provides runtimepolicy enforcement and policy

implementation for web services deployedin the Network Director container

• After a Network Director container isdefined, physical services registered inPolicy Manager can be virtualized andhosted in the Network Director container.

• Virtual Services, are defined with their ownWSDL that is accessible through the PolicyManager REST API or from NetworkDirector directly.

• Operational, Compliance and/or QoS

Policies are attached to the virtualservices/operations or the organizationwhere the virtual service resides.

Consumer

NetworkDirector

Physical Service

ServiceVirtualization

VirtualService

VirtualService

IIS Websphere

Network Director Configuration Scenarios




Network Director Configuration Scenarios

• Network Director can be configured as a standalone container instance orconfigured to run inside of the Policy Manager instance.

NetworkDirector

NetworkDirector

• Recommended Configuration• Network Director as a standalone

container/instance• Policy Manager and Network Director

run on their own ports

• Additional Configuration (non-Production)• Network Director running inside the

Policy Manager container• Network Director shares the

Policy Manager port

Policy Manager InstancePort 9900Policy Manager

InstancePort 9900

Network DirectorInstancePort 9905

Network Director Configuration Summary




Network Director Configuration Summary

The following steps are required to configure the Network Director:

• Create a new instance for Network Director (if running standalone).

– Install the Network Director feature in the new instance.

– Configure the Network Director instance.

• Install the Network Director feature into the Policy Manager instance (if running inthe Policy Manager instance) from the Admin Console.

• Define the Network Director instance in the Policy Manager Console (if runningstandalone).

Create a Network Director Instance




• The Configurator is used to create the Network Director instance.

– >./sm60/bin/startup.sh/bat configurator

• To configure the Network Director, provide the following details

– Instance name

– Admin console administrator username and password

– The port number for the Network Director instance

– The startup options (manual or service).

• If the Network Director is started manually use the following command:

– >./sm60/bin/startup.bat/sh <ND_instance_name>

• After the Network Director instance is started, the Network Director feature mustbe installed from the Admin Console.

Install the Network Director Feature




• If the Network Director is being run as a standalone container, then the Admin Consoleis accessed from the Network Director Port.

Network Director Admin Console: http://<nd_host>:<nd_port>/admin/

• Select the Network Director feature and install it.

Configure the Network Director Instance




g

• During the Network Director feature installation process, there are several tasksthat are required to configure the Network Director instance:

– Enter the WS-MetaDataExhange URLThis is the URL to the WS-MEX service in the Policy Manager.

Default: http://<policy_manager_host>:<policy_manager_port>/wsmex

– Generate the PKI Keys and Certificate for the Network Director. These keys are requiredto enable the Network Director to communicate securely with the Policy Manager.

– Start the Network Director instance with the feature installed.

Configure the Network Director instance in the Policy

Manager Console




Manager Console

• After the Network Director instance is running, the container must be defined inthe Policy Manager Console.

• Create the Network Director instance in the Service Provider Organization.

• Create a an SOA Container .

• Provide the Metadata URL (ie: http://<nd_host>:<nd_port>/metadata), for theNetwork Director.

• Provide the authentication options for meta-data retrieval.

• Load the Network Director certificate into the Policy Manager Trusted Store.

Network Director Listeners




• A Network Director instance can support three incoming protocols: HTTP, HTTPSand JMS.

• Network Director receives incoming requests on a defined listener .• Multiple inbound HTTP and HTTPS listeners are supported on a single Network

Director. Each listener must have a unique port number.

• If multiple HTTPS listeners are configured, they must share the same PKI keysand certificate.

VirtualService

Virtual

Service

Network Director

Physical Services

HTTP

HTTPS

JMS

ND Listeners

Incoming Request

Configure the Network Director Listeners

Inbound HTTP/S support




Inbound HTTP/S support

HTTP Listener : Configure the host andHTTP port number of the machine on whichthe Network Director resides.

HTTPS Listener : Configure the host andHTTPS port number of the machine on whichthe Network Director resides.

HTTPS allows the following certification options:Ignore, Accept, Require

After the listener has been configured, PKI keysmust be configured for this listener.

Configuring outbound HTTPS Support on Network

Director




Director

• Network Director supports outbound HTTPS to the endpoint using two differentmethods.

– Outbound HTTPS certificate is configured on the Network Director Used if a single certificate is used for all outbound HTTPS communication

– Outbound HTTPS certificate is configured on the virtual service Used if different certificates are required to communicate with different HTTPS endpoints.

VirtualService

VirtualService

VirtualService

VirtualService

Cert

Cert

Network Director Network Director

Endpoint(s)Endpoint(s)

Cert

Cert

Cert

Cert

Cert

Configure Network Director Listeners – JMS




• The jar files for the JMS implementation are required and need to be configured inthe Network Director instance.

• Specific properties may be required based on the implementation.

Additional propertiesto support different JMSimplementations (i.e. Static

replyTo queue vs. temporaryqueue)

Adding JAR files to Policy Manager instances




• There are times when additional jars are required in the Policy Manager/NetworkDirector environment (i.e. for JMS support).

• There are two methods to add the jar files to the configured instance:

– Add the jars to the ./sm60/instances/<instance_name>/deploy folderThis automatically creates a bundle for each of the jars added

– Create a .lst file in the ./<instance_name>/deploy folder and reference the jar files byentering the full path to the jar file or using a URL reference to the file.

• Bundles will be created for each jar file deployed into the instance.

• The bundles can be verified from the Installed Features tab of the instance Admin

Console.

Network Director Cluster




• A Network Director Cluster is alogical grouping of Network Director

container instances.

• A Network Director Cluster isconfigured to be used with a loadbalancer. This configuration forcesall consumers to route requests

through the load balancer.

• Operational Policies are applied tothe cluster and each ND instancethat is part of the clusterautomatically enforces the policy.

• A single WSDL is generated for theNetwork Director Cluster

Consumer

Physical/Endpoint webServices are virtualized andhosted in the ND cluster

Network DirectorCluster

VirtualService1

VirtualService2

Creating a Network Director Cluster




• The Network Director Cluster is configured with an access point that corresponds to theload balancer. Each Network Director instance that is part of the cluster has its own access

point.• Network Director instances are added or deleted to/from a Network Director Cluster.

• The Network Director instances and the cluster must have the same Listener name.

• Virtual Services are deployed to the Network Director Cluster.

Support for Service Manager 5.2 Legacy Containers




• Policy Manager 6.0 continues to provide support for Service Manager 5.2containers for backward compatibility. This includes Network Director and Agent

containers (contact [email protected] for specific agent support).

• Policy Manager 6.0 supports Service Manager 5.2 Network Director clusters.

• The Policy Manager 6.0 SOA Container/Cluster should be used whenever possible.

Training Use Case: Create a Network Director

Instance

mailto:[email protected]





Instance

• Create a Network Director Instance.

• Using the Admin Console, add the Network Director feature to the Network

Director instance.• Create the instance in the Engineering Organization of the Policy Manager

console.





Deployment Scenarios

Policy Manager Deployment Scenarios




• The following slides depict common deployment scenarios for Policy Manager,Network Director and Agents.

• The following features are highlighted:

– Load balancing / High Availability

– Geographical Redundancy

– Clustered environments with Network Directors deployed in the DMZ

– Last Mile Security

Load Balanced/Highly Available Environment




• Policy Manager instances are clustered.

• Network Director instances are clustered.

• Network Director resides in the DMZ.

• Network Director uses Usage Writer to sendUsage data to the Policy Manager.

Policy Manager

Cluster

Oracle 11g

RAC

Database

Network Director

Cluster

Load Balancer

DMZ

Endpoint Services

Usage Writer

Consumer/

Application

Geographical Redundancy




• Database Replication

• HA/LB Policy Managerenvironments

Last Mile Security




• Agent installed in the App Serverintercepts requests to the endpoint

services.• Policy applied to services hosted in the

App Server.





Registering Services

Registering Services in Policy Manager




• All services registered in Policy Manager are defined by a WSDL to facilitateservice consumption, versioning, mediation and other advanced governance

scenarios.

• The basic Policy Manager service (WSDL) structure requires:

– XML Schema to define the data types that will be passed.

– Interface definition referencing the schema that defines the service operations.

– One or more bindings defining the different ways to access the interface (i.e. SOAP,REST, POX etc.).

– Service definition to provide a categorized, searchable version managed object.

WSDL

Schema

Interface Binding

ServiceDefinition

Service Types: Physical and Virtual Services




• Policy Manager supports different types of services:

– Physical Service

– The physical endpoint (i.e. SOAP service, REST service).– Virtual Services

– Created from a physical service, an existing interface or schema.

– Deployed/hosted and managed in a Network Director instance or cluster.

– A single virtual service is a proxy for all, some or a combination of operations from a singleor multiple services.

– Virtual Services provide a way to route requests based on specific content, providemessage transformation, aggregate services and provide protocol mediation.

Network Director

Virtual ServicesPhysical Services

Policy Manager

Service Types: Discovered Services




• Discovered Service

– Some SOA Agents support the discovery of services that are deployed in the application

server to be automatically registered in the Policy Manager.– Discovered services can optionally be managed (i.e. monitored and/or secured)

Service Discovery

Physical Services

Application Server

SOAAgent

Discovered Services areautomatically registered inPolicy Manager

Policy Manager

Service Types: Aggregate Service




• One advantage of service virtualization, is the ability to create an Aggregateservice.

• An Aggregate Service combines operations from multiple physical servicesregistered in Policy Manager and exposes this service to the consumer as a singlevirtual service with its own WSDL

Oprn1

Oprn5Oprn6

Network Director

AggregateVirtual Service

Physical Services

Oprn1Oprn2oprn3

Oprn4Oprn5

Oprn6

Service1

Service2

Policy Manager





Registering a Physical Service

August 2010

Registering a Physical Service – WSDL Location




• The physical service is registered using an existing WSDL, schema, interface or simplydefined.

• To register the physical service in Policy Manager:

– Determine the organization under which to create the service

– Register the service using one of the methodsRegister the service from WSDL• WSDL URL: Valid URL to the WSDL• WSDL Path: Path to the WSDL file• Zip Archive Path: Load the WSDL from

a zip file. This option is used whenthere are WSDL’s containing imports and/or references to schemas or WSDLs

Register the Service usingexisting interfaces Use an existing interface from the PolicyPolicy Manager

Create service from schemaUse an existing schema defined in thePolicy Manager.

Register the service without WSDLCreates a “placeholder” for the service andassociated documentation.

Physical Service – Service Details




• When a service is registered, the service details fields are populated based on thecontents defined in the WSDL. The Service Name, Namespace URI and Localpart

are required to register the service.• The service key is a UDDI formatted key and can be entered manually or

generated automatically (if left blank).

• Select the Provider organization (Organization providing the service toconsumers).

Physical Service – Service Management Options




• When the physical service is created, it can optionally be managed.

• A service managed in Policy Manager is defined as a service to which Policies can

be applied and the service can be monitored and secured through the use ofthese policies. Network Director and Embedded Agents manage services.

• There are three management options available when the physical service isregistered:

– Do not manage: Do not manage the service (i.e apply security/monitoring policy).Register the physical service in the Policy Manager’s Registry only.

– Manage within container: Manage the service through an Embedded Agent– Manage through a virtual service: Manage the service by virtualizing the physical service

and hosting it on a Network Director container.

The Physical Service - Details




• When the physical service is created it is displayed in the Policy Managerorganizational tree with all associated service detail.

• By default, the Service Workflow process is initiated. A default workflow issupplied.

• The service can be checked for compliance by manually running the compliancecheck or can be invoked automatically through the workflow process.

Service Details

ComplianceResults

Workflow

Metadata(attachments, tags)

OrganizationConsumers

PolicyAttachments

Compliance Support in Policy Manager




• After a service is registered in Policy Manager, the service can be checked forcompliance.

• Policy Manager provides Compliance checking by providing a set of Compliancepolicies.

Document Style TestTests for document style WSDL

Has Keyword TestTests whether keyword metadata hasbeen attached to the service

SOAPAction Test Tests the request message to determineif the SOAPAction header is present

WS-I Basic Profile 1.1

Tests the service to determine if itcomplies to the WS-I Basic Profile andprovides a report

Attaching Compliance Policies




• Compliance Policies are attached at the Organization level (and inherited byservices in that organization) or to the service.

Viewing Compliance Results




• The Compliance Results portlet allows you to run the compliance tests and viewthe results (pass/fail) for each of the Compliance Policies attached to the service

and/or organization.

Training Use Case: Registering a Physical Service




• Register the AccountManager physical service in the Engineering Organization.This service has 5 operations: listAccounts, getBalance, withdraw, deposit and

transfer.• Run the Compliance Check on this registered service.





Registering a REST Service

August 2010

Registering a REST Service: Schema Options




• To govern a REST service a user has two choices when registering the service:

1. Formally define and govern a schema for their service

Use this option if versioning of the interfaces and/or mediation is required

2. Use existing schema elements from standard schemas

Use this option if only monitoring and securing of the service is required

GovernanceMediation

Versioning

VERSIONED

SCHEMA

Monitoring SecuritySTANDARD

SCHEMA

Steps Required to Register a REST service




• Choose a namespace and service name for the REST service being created.

• Either upload a schema or use an existing schema to create the physical service.

• Define the interface for the REST service by defining the operations.

• Define the input, output and fault message types for each operation.

• Define the binding details/serialization types for each operation.

• Virtualize the physical service and host it on a Network Director instance orcluster.

• Define the access point for the physical REST service endpoint.

Registering a REST Service - Steps




• Choose a namespace and service name for the REST service.

• Create the physical (REST) service from an existing schema.

• Create an interface and add the operations the interface will provide

Registering a REST Service: Input, Output and Fault

Message Definition




• Define the input, output and fault messages for each operation

Registering a REST Service: Binding Details




• Define the binding details for the REST service, including the Method being usedto invoke the service, the URI Syntax and the Input, Output and Fault

Serialization types.

• The Serialization type map to the HTTP content-type header or the request,response or error returned

The URI Syntax, can containvariables that are used as part

of the URL. Variables are definedin curly brackets.

Output serialization type of “any” passes through the content-typeheader sent from the endpoint.

Registering a REST Service: Virtualize the service




• After the service has been defined it can be virtualized and hosted on a NetworkDirector container.

Use this flag to ensure the HTTPheaders are passed to theendpoint

Registering a REST Service: Adding an Access Point




• Add an Access Point (base URL) for the REST service.

• The REST Service:

– Has a WSDL defined in the Policy Manager– Has been virtualized and hosted on a Network Director container

– Can be secured and managed through the use of Policy Manager policies

Training Use Case: Registering a REST Service




• A weather service that returns weather data as an XML document for a given zipcode will be registered in Policy Manager.

• To register this service an Interface and Binding will be created for this service.

• We want to be able to monitor the activity to this service.

P li M TM 6 0





Configuring Virtual Services

August 2010

Virtual Service Overview




• After the Physical service is registered, it can be virtualized and hosted on aNetwork Director instance or Network Director cluster.

• The virtual service routes requests to the physical service. Policies are applied tothe virtual service.

• A single instance of Network Director or a Network Director Cluster hosts anunlimited number of virtual services

• Virtual services provide many benefits such as:

– Endpoint transparency from the consumer If the endpoint moves, the consumer does not have to be notified

– Service aggregation Multiple services and operations in the service are aggregated to create a single virtualservice with its own WSDL

– Routing Requests are routed between services based on message content

– XSLT Transformation

– MediationRequests can be received over HTTP/S and sent to a JMS, SOAP <->REST, XML endpoint,JSON <-> SOAP

Service Virtualization




• Services are virtualized in a Network Director instance or cluster. Policies areapplied and enforced at the virtual service.

serviceA_vs

serviceB_vs

Network Director

Web Service ServiceA

SOAP Web ServiceB

/serviceA_vs

/serviceB_vs

Physical ServicesVirtual Services

serviceA_vs

serviceB_vs

Network Director Cluster

ServiceA

ServiceB

/serviceA_vs

/serviceB_vs

Application/Partner/Consumer

Application/Partner/Consumer

End User

End User

Services hosted in a NetworkDirector cluster are automaticallydeployed to the ND instancesin that cluster

Agent

GET POST

Creating a Virtual Service




• Virtual services are created from a registered physical service or existing interface.

• A name, Namespace and Localpart (virtual service name) for the virtual service are required.

• The virtual service is hosted on a Network Director container or Network Director Cluster.

Creating a Virtual Service – Define the Binding Details




• Binding details are required for the virtual service.

• If multiple ports are being defined for the virtual service, each port must have a

unique name.

Either the SOAP 1.1 and/or the SOAP 1.2 bindingdetails can be entered.

Creating a Virtual Service – Define the Access Point(s)




• Each virtual service requires a context path(s) when it is hosted on the NetworkDirector.

• The Listener Address + Context Path = URL exposed to the consumer.

Network Director Hosted Services




• When the virtual service is created, it is hosted on the Network Director container.

• Access Points for all services that are available on the Network Director are

displayed from the Network Director Container.• Auditing, QoS, Compliance and/or Operational Policies can be attached to the

virtual service.

Virtual Service Details




• All the virtual service details are displayed on the Details Sub-Tab.

• The Actions in the Actions Portlet are specific to the virtual service.

Service Actions

Service Workflow

ServiceDetail Summary

Service PolicyAttachments

Service PolicyCompliance

ServiceConsumers

Service Metadata

Virtual ServiceWSDL

Virtual Service - Operations




• All operations that can be invoked for the service and the corresponding interfaceare displayed in the Virtual Service Operations Sub-Tab

• All operations and their corresponding interfaces are displayed. Routing from thevirtual service operation to the endpoint service operation are managed here.

Virtual Service – Operation Implementation




• When a service is virtualized, the Network Director will either strip all the HTTPand SOAP headers or preserve these headers.

• These options are configurable on a per operation basis from the Operation ->Implementation sub-tab

Virtual Service - Bindings




• The virtual service bindings screen, displays the bindings for the virtual service

• The service could contain a single binding (i.e. for SOAP 1.2) or multiple bindings,i.e SOAP bindings, XML bindings and/or HTTP bindings.

Virtual Services – Access Points




• The Access Points sub-tab, displays the URL information for each endpoint(service exposed to the consumer) defined for the virtual service.

Virtual Service – Categorization




• Categorization facilitates service searching and can be used in the serviceworkflow.

– Policy Manager allows you to create your own category schemes and attachthem to the virtual services.

Virtual Service – Denial of Service (DOS) Rules




• Denial of Services Rules can optionally be assigned to the service to limit the IPaddresses allowed to access the service, the size of the message and/or the

throughput rate.

Virtual Services - Monitoring




• Service monitoring displays a real-time view of the virtual service activity, alerts,usage log data, historical charts/data and service dependencies for the virtual

service.

Creating an Aggregate Service




• A virtual service can also be configured as an “aggregate” service in whichmultiple operations from two or more services are combined to create a singlevirtual service.

• The aggregate virtual service is exposed as a single service to the consumer.

• Aggregate services require that the physical service or interface are registered inthe Policy Manager.

• A new interface and binding are required for the Aggregate service.

• The Aggregate Virtual Service is created using the ”aggregate” interface.

VirtualService

Oprn1Oprn5Oprn6

AggregateVirtual Service

Oprn1Oprn2oprn3

Oprn4

Oprn5Oprn6

Physical Service1

Physical Service2

Interface-1oprn1

Interface-2Oprn5

Oprn6

InterfaceAggregate

Oprn1Oprn5Oprn6

Consumer

CreateBinding

Create the Routing from the Aggregate Virtual Service

to the Physical Service operations




• Routing is required from the aggregate virtual service to the correspondingphysical service operations.

VirtualService

Oprn1Oprn5Oprn6

Oprn1Oprn2oprn3

Oprn4Oprn5Oprn6

Interface-1oprn1

Interface-2Oprn5Oprn6

InterfaceAggregate

Oprn1Oprn5Oprn6

Routing from Virtual to Physical Service required

Virtual to Physical Service

Training Use Case: Virtualizing the Services




• The AccountManager and Weather services will be virtualized and hosted on theNetwork Director instance.

• Prior to sending requests to these services, a contract is required. An Anonymouscontract will be configured.

• We will test sending requests to these services using SOAPUI and the browserand monitor the activity through these virtual services.

AccountManagerVirtual Service

Network Director AccountManager Service

Virtual ServicesBrowser

Weather VirtualService

Weather Service

SOAPUI




y g


Operational Policies

Policy Manager Operational Policies




• There are three types of policies supported by the Policy Manager:

– Operational Policies are used to secure, manage and monitor services at runtime.

– Compliance Policies ensure that services adhere to a specified set of rules and guidelines.

– QOS Policies ensure that a specified quality of service is met based on contractualobligations and/or defined requirements.

• Operational Policies can be applied to an Organization (and inherited by allservices in that organization), Service and/or optionally to service operations.

• Multiple Operational Policies can be applied to an organization, service oroperations (i.e. can have multiple authentication types for a single service).

• Operational Policies can be applied to the “next hop” web service allowing theNetwork Director to implement the Policy required for the next hop.

• Operational Policy templates can be copied and moved to any organization.

Operational Policy Types




• Single Policy

– A single Operational Policy definition

• Aggregate Policy

– A collection of Operational Policies

• Pipeline Policy

– Legacy Service Manager 5.2 PolicyTemplate using pipeline policycomponents

“Out of the Box” Operational Policies




• The following policies can be combined to create Aggregate Policy Templates orused as stand-alone Policies (if allowed).

Policy Name Description Aggregate Policy Used when combining multiple policies

Authentication Policy Used to authenticate consumers or end users

Authorization Policy Use to authorize end users

HTTP Security Policy Used to secure HTTP connections or to provide HTTP authentication

WS-Addressing Policy Used to add and verify WS-Addressing header information

WS-Auditing Message Policy Used to audit the full message or parts of the message specified by an XPATH

and/or namespace. Requires a service policy as well.WS-Auditing SOAP Message Policy Used to audit the full SOAP message or parts of the message specified by an

XPATH and/or namespace. Requires a service policy as well.

WS-Auditing SOAP Service Policy Used to audit the SOAP service

WS_Auditing Service Policy Used to audit a service

WS_Auditing Transaction Tracking Policy Used to add transaction tracking data to requests sent between SOA components

WS-Security Asymmetric Binding Policy Used when the request and the response are secured by different keys

WS-Security Message Policy Use to sign and encrypt messages at the message (request/response) level

WS-Security Supporting Tokens Policy Used to define the type of tokens required (i.e. X.509, WS username/password

etc.) in the message

WS-Security Symmetric Binding Policy Used when the request and response are secured using the same key

WS-Security Transport Binding Policy Used for securing the message at the transport layer (i.e. HTTPS)

XML Policy Use to create an XML policy

“Out of the Box” Operational Policy Templates

Th i b l d ib h f h f h b O i l P li l h b li d




Specification/Policy Name Policy Type Description

AnonymousForCertificate Aggregate Uses the service certificate to sign and encrypt the

message

BasicAuditing Policy Collects usage data

CertificateOverTransport Aggregate Requires a client X.509 certificate

DetailedAuditing Policy Collect usage and recorded detail data

KerberosOverTransport Requires a client Kerberos token

MutualCertificateSignEncrypt Aggregate Requires that the request and response are sign and

encrypted. The certificates used to sign and encrypt

the request and response are not the same.

MutualCertificateSignOnly Aggregate Requires that the request and response are signed

using different keys (i.e client signs the request,

service signs the response).

MutualCertificateSymmetricBinding Aggregate Requires that both the request and the response are

signed using the same key.

SAMLOverTransport Aggregate Requires a SAML assertion

UsernameForCertificate Aggregate Requires a randomly generated symmetric key to

encrypt the username and password and sign the

request. Service certificate is used to encrypt the

symmetric key.

UsernameOverTransport Aggregate Require a client WS-S Username token

The matrix below, describes each of the out-of-the-box Operational Policy templates that can be applied tomanaged services at runtime.

Applying Operational Policies




• Policies can be applied at the Organization, Service or Service Operation level

• Multiple policies can be applied to any of these objects

Policies attachedat the Organization

Policy attached at theService

Service WSDL and WS-Policy Definition




• Policy Manager supports WS-Policy. WSDL’s for services with Policies attachedare generated with WS-Policy definition included.

…

Operational Policies – Enforcement/Implementation

A O ti l P li id th h i t f d/ i l t




• An Operational Policy provides the mechanism to enforce and/or implement management and security requirements.

• The Enforcement and Implementation options can be enabled/disabledbased on the runtime requirements.

• Enforce = Enforce the Operation Policy applied to the virtual service.

• Implement = Implement the Operational Policy at the next hop.

Network Director

End Point

Operational PolicyImplementation

Consumer

VirtualService

/service_vs0

Operational PolicyEnforcement

Policy Enforcement/Implementation Configuration

P li P i (E f t d I l t ti ) i fi d f th




• Policy Processing (Enforcement and Implementation) is configured from thevirtual service Actions Portlet.

• The Default setting is to Enforce and Implement the Policies.





Operational Policy:

Use Case Scenarios

August 2010

Use Case: WS-S Username/Password Authentication

Th f ll i lid d ib i i d i l d th




• The following slides, describe various use case scenarios and include theOperational Policies required at the virtual service and the endpoint

End Point

• UsernameOverTransport

• End User Authentication

VirtualService

/service_vs0

WS-S Username/PasswordTimestamp

Consumer Operational Policy Definition at the Network

Director

Operational Policy Definition

at the Endpoint

Consumer sends a WS-S request

containing a WS-S Username and

Password and a timestamp

Response received containing a WS-S

timestamp

• Username over Transport

• Authentication (End User)

Username and Password authenticated against

the configured domains in the Authentication

Policy

None

ConsumerWS-S Timestamp

Use Case: X.509 Authentication and Signature

Verification of the timestamp




End Point

• X.509 Authentication• Verify signed timestamp

element

VirtualService

/service_vs0

X.509 CertificateTimestamp Signed


Director

Operational Policy Definition at

the Endpoint


containing an X.509 Certificate,

timestamp and the timestamp signed

using the private key of the consumer to

the virtual service

• CertificateOverTransport

• Authentication

X.509 certificate is authenticated against the

domains configured in the AuthenticationPolicy.

Timestamp signature is verified

None

ConsumerTimestamp Signed

Use Case: WS-Username/Password Authentication and

Basic Authentication at the Endpoint




End PointConsumer

VirtualService

/service_vs0

WS-S Username/Password HTTP Auth

• WS-S Username/PasswordAuthentication

• Verify timestamp is in therequest

Basic Authentication


Director


the Endpoint


containing a username, password and

timestamp

• UsernameOverTransport

• Authentication

Username and Password are authenticated

using the domains configured in the Authentication Policy

Timestamp is checked

HTTP Security Policy

Request is sent to the endpoint

containing the username/password

credentials in the HTTP header.

WS-S Timestamp

Use Case: Signature and Encryption




End Point

X.509 AuthenticationSignature Verfication

WS-Decryption (Body)


using application credentials

Consumer

VirtualService

/service_vs0

X.509 CertificateSigned (client)Encrypted (Body) HTTP Auth

X.509 CertificateSigned (service)Encrypted (Body)


Director


the Endpoint


containing an X.509 certificate that is

signed and with the body encrypted

using the key of the service.

• MutualCertificateSignEncrypt

• Authentication

Username’s X.509 certificate is authenticated

using the domains configured in the Authentication Policy

Signature is verified using the client ‘s key

Body is decrypted using the service’s key

Timestamp is checked

HTTP Security Policy

Request is sent to the endpoint

containing the application ID and

password credentials in the HTTPheader.

The Outbound Identity Mapping is

configured on the virtual service to

map the Source Subject Category

to the application ID and the

Outbound Subject Category to End

User

Operational Policy Summary

• Policy Manager ships with Out Of The Box Policies that reside in the root Policies




• Policy Manager ships with Out-Of-The-Box Policies that reside in the root Policiesfolder in the Policy Manager Console.

• Custom Policies can be created as required under any Organization Node.

• Operational Policies contain one or multiple Policy definitions.

• Operational Policies can be applied to an Organization, Service and/or Operation

input and/or output message.

• Operational Policies are applied to services managed by an Embedded Agent,virtual services that are hosted in a Network Director container or to the “nexthop” services that are registered in Policy Manager.





Integration with 3rd Party Identity Systems

Policy Manager and Third Party Identity Systems

• Policy Manager supports the creation and integration with third party identity




• Policy Manager supports the creation and integration with third party identitysystems to leverage existing identities for use in authentication or authorizationoperational policies or to enable login into the Policy Manager console.

• Identity System Types supported “out of the box” include:

– Cookie Authentication Module *

– Directory Server (LDAP)

– Kerberos

– SAML Authority

* Used between SOA components

Configuring an Identity System

• Identity systems are configured from the Configure->Security tab of the Policy




• Identity systems are configured from the Configure->Security tab of the PolicyManager console.

• Each Identity system requires configuration details specific to the Identity systembeing configured.For example the following information is required if the identity system is an LDAPserver: LDAP Server host, port, bind DN and base DN’s for users and group.

Identity Systems in Service Manager

• User/IDs/Groups from the configured Identity Systems (External Domains) can be




• User/IDs/Groups from the configured Identity Systems (External Domains) can beused in Policy Manager to support the following scenarios:

– Access to objects (Organizations, services, contracts, policies, containers) in the PolicyManager console.

– Organization/Application Identities used when defining a contract.

– At runtime to authenticate users/identities invoking managed services.

– At runtime to authorize users/groups invoking managed services.

Training Use Case: WS-S Username/Password

Authentication




• Collect Detailed Auditing data to view the request and responses messages.• Create an Authentication Policy.

• Use the UsernameOverTransport Policy to authenticate the user using WS-SUsername/Password.

End Point

WS-S Username Authentication

Consumer

VirtualService

/service_vs0

WS-S Username

Training Use Case: End User Authorization




End Point


Consumer

VirtualService

/service_vs0

WS-S Username

Authorization

• Collect Detailed Auditing data to view the request and responses messages.

• Use the UsernameOverTransport Policy to require the WS-S Username token

• Create an Authentication Policy to authenticate the user

• Create an Authorization Policy to authorize the user to invoke the service

• Create an authorization rules to define the service the user is allowed to invoke.

Training Use Case: WS-S Username/Password

Authentication and Basic Authentication Credential Insertion




• Collect Detailed Auditing data to view the request and responses messages.• Create an Authentication Policy.

• Use the UsernameOverTransport Policy to authenticate the user using WS-SUsername/Password.

• Create a Policy to send Basic Authentication credentials to the endpointwebservice

End Point


Consumer

VirtualService

/service_vs0

WS-S Username


Consuming the Services

• After a service is registered in Policy Manager, checked for Compliance, and




After a service is registered in Policy Manager, checked for Compliance, andmanaged by Network Director or an Embedded Agent, the service is still notavailable for consumption.

• The consumer must request a contract from the provider or the service providermust offer a contract to the consumer to enable the consumer to invoke theservice(s) hosted on the Network Director or an Embedded Agent.

• A contract defines the service agreement made between the consumer and theprovider of the service.

A CONTRACT IS REQUIRED TO INVOKE MANAGED SERVICES





Contract Management

Defining Contracts

• When a service is registered and managed in Policy Manager, a contract is




When a service is registered and managed in Policy Manager, a contract isrequired to consume the web service.

• Contracts are “OFFERED” by the provider or “REQUESTED” by the consumer.

• Workflow can be used to control the state of the contract and determine whetherthe service requires approval, is in a draft state or is activated (services can beconsumed). A default contract workflow is shipped with the product.

Request a Contract

Offer a Contract

No Contract = No services can be consumed

Contract Scope

• Contract Scope is comprised of:




p p

– Services that are available to the consuming organization.

– Identities from a consuming organization that are authorized to access the services beingoffered.

– QOS Policies (SLAs) that specify the service level defined between the consumer andprovider of the web service(s).

• Policy Manager supports two types of Contracts: Anonymous and Named

ConsumerOrganization

Identities

Contract

IdentitiesServices

QOS Policies

ProviderOrganization

Services

Anonymous Contract

• Anonymous Contract




y

– Allows any consumer the ability to access the services being offered by the Provider aspart of the contract

Contract Types – Named

• Named Contract




- Only application/consumer identities defined in the contract are allowed toinvoke the services

- Providers can Offer the consumer a Named Contract.

- Consumers can Request a Named Contract for a specific service.

Named Contract Use Case #1: Application callingservice

• A Named contract is used when an application id is invoking a service.




• A Named contract requires authentication and implies authorization as part of thecontract itself.

• In this use case, an end user logs into a portal and is authenticated at the Portal.Once authenticated the end user can request specific services. In this case theportal application id is passed to the Network Director andauthenticated/authorized against the contract definition.

PortalApplication

UserRepository

Userid/Password Appid/Password

EndpointWebservice

UserId/Password

ContractEnd User

AppIDs

Named Contract Use Case #2: Business Partnerscalling service(s)

• Named Contracts can also be used in a B2B use case, where business partners




are consuming offered services.

• A contract is configured for each BusinessPartner defining the services they areallowed to invoke.

• Creating these contracts, provides visibility to the service usage by each businesspartner.

Business

Partner #1

EndpointWebservice

Contract #1

EndpointWebservice

EndpointWebservice

BusinessPartner #2

BusinessPartner #3

NetworkDirector

Contract #2

Contract #3

Anonymous vs. Named Contracts

• The table below summarizes the differences between an Anonymous and a




Named Contract

Anonymous Named

Applies to virtual services Yes Yes

Applies to physical

services (managed by

Embedded Agent)

Yes Yes

Applies to unmanagedservices No No

Define consumer identities No Yes

Authentication Policy

RequiredNo Yes

Authorization Policy

RequiredNo No

QOS Policies applied to

the contractYes Yes


Contract Creation




Contract Creation

Create a Contract – Set the Timeframe and AccessControl

• Define the contract name, timeframe and access control.




• An Anonymous contract does not require any authentication by the consumingorganization.

• A Named contract requires that credentials be passed as part of the request and theidentity authenticated against the configured consumer identifies.

Named Contract

Access Control

Anonymous ContractAccess Control

Create a Contract – Select Provider and ConsumerOrganizations

• Select the PROVIDER (for Anonymous and Named contracts) and CONSUMER




organization (for Named contracts)

Select the Provider Organization when defining an Anonymous or a Named Contract.

Select the Consumer Organization when defining aNamed Contract.

Create a Contract - Contract Summary

• After the contract is created, the Contract State is governed by the Workflow




process. The workflow is initiated and the contract is in DRAFT state.While in a DRAFT state the services are not available for consumption.

• The contract must be Activated before the consumer can invoke the services.

Create a Contract – Define the Scope

• Define the Contract Scope, by selecting the services that are included in this contract.

f f




• All services for an Organization can be included in the scope (if the Organization is keptchecked).

• Specific services and/or operations for can be included in the scope by selecting theseindividually.

Service Operationsincluded in the contract

All services in theTraining Organizationincluded in the contract

Create a Contract – Define Consumer Identities

• Named contracts require that Consumer/Application Identities are defined in theC i ti




Consumer organization.

• Consumer/Application Identities can be defined in the Policy Manager LocalDomain or the identities can exist in an External Domain.

Add Identities to theLocal Domain from theOrganization Actions Portlet

Add Identities from anExternal Domain

Create Contract – Add Identities to the Contract

• Add Consumer Identities to the contract




Select all

identities in theorganization

Select a individualidentities in theorganization

Attach a QOS Policy to the Contract

• Service Level Agreements (QOS Policies) can optionally be applied to a Contract.




Named Contract: Authentication Policy

• A Named Contract requires that the Authentication Operational Policy is attachedto the se ice to a thenticate cons me identities defined in the Named Cont act




to the service to authenticate consumer identities defined in the Named Contract.

• The Subject Category must be set to Consumer in the Authentication Policy.

• Domains configured in the Authentication Policy can include the Local Domainand/or External Domains.

Verifying Named Contract Consumer Identities

• The following verification steps are performed when a request is received by amanaged service:




managed service:

1. Verify a valid contract (Anonymous or Named) is in place for the service (Activated).

2. Verify that the operation being invoked is included in the contract.

3. Verify the Application Identity credentials being past in the request are valid and definedin the Named Contract.

4. Forward the request to the endpoint web service.

ConsumerRequest

Network DirectorOr

Embedded Agent

AuthenticationPolicy

Identity Authenticated/Authorized EndpointWeb service

External

Domain

Send ApplicationCredentials

Verify the identity and serviceare defined as part of thecontract

Named

Contract

App IDServiceSLA

Named Contract vs. End User Authorization

Below are differences in the configuration between defining a Named Contract andconfiguring End User Authorization




configuring End User Authorization.

• Named Contract Authorization

– Operational Policy that includes a method of authenticating the identity and theAuthentication Policy (with a domain(s) selected and the subject category set toconsumer).

– Named Contract must be defined that includes consumer identities allowed to invoke theservice(s).

• End User Authorization

– Operational Policy that includes a method of authenticating the end user, theAuthentication Policy and also includes an Authorization Policy.

– Authorization Rules defined at the Provider Organization.

– Anonymous Contract.

Contracts Summary

• To consume a service managed by the Policy Manager, a Contract must bedefined for that service




defined for that service.

• Contract scope consist of: Services, Identities and QoS Policies

• Two types of contracts are supported: Anonymous and Named

• Named Contracts require identities to be added/created in the consuming

organization and an Operational Policy attached to the service that includes the Authentication Policy .

• By default, the Contracts must be activated before a service can be invoked by aconsumer

Training Use Case: Creating a Named Contract

• The QA Organization is the Consumer Organization, therefore OrganizationIdentities (i e business partners application ids) will be created in the QA




Identities (i.e. business partners, application ids) will be created in the QAOrganization.

• A Named Contract will be created between the Engineering Organization and theQA organization. The QA organization consumer ids will be included in theContract and allowed to invoke the AccountManager virtual service.

• WS-S Username will be used to authenticate the Consumer Identities.





Quality of Service (QoS) Policies

QoS Policy Types

• Various types of QoS Policies are supported in Policy Manager




– Service Level Agreement

– Bandwidth (with Option Pack)

– Throughput (with Option Pack)

Alert Overview

• Before a Service Level Agreement QoS Policy is defined, a custom alert code isrequired to trigger the SLA violation.




required to trigger the SLA violation.

• Actions can performed when an alert is generated:

– Alert notification can be forwarded via SNMP

– Alert notification can be sent via SMTP

– Alerts can initiate the invocation of a management script

• The SOA Alert SNMP MIB is provided for SNMP Management Systems(./sm60/mib)

ManagementScript

Alerts

Creating a Custom Alert Code

• To define a QOS Policy a customalert is required to identify the SLA




alert is required to identify the SLAviolation.

• Create the Alert from thesub-tab on the Alert Tab.

• Custom Alert Codes must startat 1000000.

• By default, all alerts are logged to thePolicy Manager database. The optional

alert actions can be configuredas required.

Alert Action: Management Scripts

• Invokes a script upon receipt of an alert.

• Example: Process to monitor the disk space when capacity hits a threshold




• Example: Process to monitor the disk space, when capacity hits a thresholdsends an alert to the Alert Manager, a script is invoked to archive the log files to

another location

Alert Action: Forward SNMP Alerts

• Configure Policy Manager to forward specific alerts to an SNMP Managementsystem (i.e. HP Openview, Tivoli NetView, BMC Patrol).




system (i.e. HP Openview, Tivoli NetView, BMC Patrol).

• The Policy Manager MIB is available: ./sm60/mib/soa.mib

Policy Manager Alerts: Forwarding

• Alerts that have been forwarded to an SNMP Manager contain all the alert details.




Alert Action: Email Forwarding

• Email notifications can be generated when a specific alert or alerts are received.

• SMTP Server information is required to forward the alerts




• SMTP Server information is required to forward the alerts.

Alert Manager Summary

• Policy Manager ships with a set of standard alert codes. Each alert code isconfigured to be logged to the database by default.




configured to be logged to the database by default.

• All alert codes whether out of the box or custom codes can optionally beconfigured to:

– Send email notifications

– Forward SNMP notifications

– Invoke a management script

• Custom alert codes are created when necessary. Custom alert codes begin at1000000.

• Custom alert codes are created to indicate QoS violations.


Creating QOS Policies




Creating QOS Policies

Policy Manager: QOS (Quality of Service) Policies

• QOS Policies




– Used to define an acceptable Quality of Service between the consumer and

provider of a services.

– Failure to meet the defined QOS, results in the generation of a custom definedAlert Code.

– QOS Policies can be applied to Organization(s), Service(s) and/or Contract(s).

Creating an QOS Policy

• Select the custom alert code used to indicate an SLA violation.

• Define the metrics on which the SLA will be measured.




Define the metrics on which the SLA will be measured.

• Specify the time frame for which the SLA is valid.

Define SLA Metrics Define SLA Access Time

QoS Policy: Defining the Metrics




• Metrics• Response time: Maximum or minimum response time for the

interval• Number of faults: absolute number of faults for the interval• Usage Count: Total usage count for the interval (must have usage/auditing Policy applied)• Request Message Size: Maximum or minimum request message

size for the requests under consideration

• Interval• Any interval SLA gets evaluated every 1 minute• 15 minute interval SLA gets evaluated every 1 minute (i.e 9:00-9:15, 9:01-9:16)• 1 hour interval SLA gets evaluated every 15 minutes• 1 day interval SLA gets evaluated every 1 hour• 1 week interval SLA gets evaluated ever 1 hour• 1 month interval SLA gets evaluated every 1 day

Assigning the QoS Policy to a Contract

• If the contract is in an active state, a new version of the contract is required toattach the SLA to the contract.




• The new version of the contract must be Activated .

When the contractis activated, to makeany modifications, anew version of the

contract must bestarted

Attach the Policy tothe Contract

Assigning the QoS Policies to Organization(s) orService(s)

• QoS Policies can optionally be assigned to a service and/or organization throughthe Policy Attachments Portlet.




• SLA violation alerts are generated for each QoS attachment.

SLA Violations and Clears

• Whether an SLA is tied to a contract, organization and/or service an alert is generated whenthe SLA has been violated.




• SLA alerts are sent on change of state for the SLA binding or SLA contract. When an SLA

continues to fail, a new alert is not generated• SLA Violations are visible from the Workbench or Alerts Tab

• When the SLA has been cleared (i.e. no more violations within the time interval defined), thealert code: 402013 is sent.

Training Use Case: QoS

• The Engineering Provider is requires a QoS policy that alerts them when the QAorganization has sent more than 3 requests to the AccountManager service.




• This QoS Policy will be attached to the Named Contract.


Object Based Security/Role Based Access




Configuring Role Based Access

• The Policy Manager Console Application provides delegated administration of theSOA infrastructure through the use of role based access (object based security).




• Roles are defined with privileges to specific Policy Manager Objects. These roles

are assigned to users and/or groups.

• Policy Manager ships with Out-of-the-box roles. Custom roles can be defined.

Default and Custom roledefinition and modificationis done at the Registry Level

Object and Associated Privileges

• Below is matrix displaying the Objects and the privileges that can be assigned toeach.




• The Red X’s indicate the privileges required to create a role with only read and

monitor permissions to the services in an organization.

Organization Service Contract Container Policy Identity

Full

Control

X X X X X X

Add X X X X X X

Read X X X X X X

Modify X X X X X X

Delete X X X X X X

Monitor X X X

Assign

Policy

X X X

Read asProvider

X

Approve X

Approve

Contract

X

Host

Service

X

System Administrator Role

• The System Administrator role is a privileged role that gives a user and/or groupfull access to the Policy Manager. The users/groups created with this role haveth i il th “ d i i t t ” th t i i iti ll t d d i th




the same privileges as the “administrator” user that is initially created during the

configuration process.• The System Administrator role is assigned globally (Registry Node) and can not

be assigned at the Organization Level.

Creating Custom Roles

• Create Custom Roles from the Registry level of the Organization Tree.

• Assign the required privileges to the selected objects based on the role




requirements.

Assigning Users/Groups to Roles

• Users and/or Groups can be assigned to Global Roles or Roles assigned to anOrganization.




• The Users or Groups that are assigned to a role can be defined locally or in an

exist in an External Identity System.• Global Roles apply to the Policy Manager system.

Assign users and/or groupsto the Global roles

Global RolesOut-of-the-box andcustom roles aredisplayed

Assigning Roles to an Organization

• Organizational Roles apply to the Organization to which the Role is “attached” to.

• Multiple roles can be attached to a single organization.




• User/Group assignment to the roles defined for a specific organization areconfigured from the Security sub-tab of the Organization.

Viewing the Organization from the Console

• Organization Roles limit the objects in the organization that are accessible to theusers and/or groups that are assigned to the configured role.




Organization View asAdministrator

Organization View as aREAD Only user

Training Use Case

• Create a user with access to only the Engineering Organization that is allowed toread the services, monitoring data and view the policies for that organizationonly




only.

• Note the difference in the Organization Tree.


Monitoring Policy Manager




Monitoring Data in Policy Manager

• The Policy Manager provides monitoring for all the components and services beingmanaged by the Policy Manager.




• The types of monitoring available include:

– Real-time monitoring Activity for a 5-60 minute timeframe

– Usage Monitoring/Basic Auditing

Message metrics about the request and responses being processed by the servicesmanaged by the Policy Manager

– Recorded Data/Detailed Auditing

The full request and response data including headers. Used primarily for troubleshooting.

– Historical Data

Monitoring data collected over a period of time for trend analysis.

– Dashboard

Provides a snapshot view of the activity for a service(s). Multiple Dashboards areallowed. Dashboards can be created using various search criteria.

Real-time Monitoring

• Real-time monitoring provides a real-time snapshot of the requests being sentthrough a service in a 5, 15 or 60 minute interval.




• Successful requests and faults are displayed as well as the average response time

Usage/Basic Auditing – Organization Data

• Usage/Basic Auditing data can be collected for all services that are beingmanaged in the organization.




Usage/Basic Auditing - Service Data

• Usage or auditing data can be collected for any service being managed by thePolicy Manager.

The Basic Auditing Operational Policy collects message metrics for each request




• The Basic Auditing Operational Policy collects message metrics for each request

and response.• All the auditing data is stored in the database

Detailed Auditing Operational Policy

• Records the full request and/or the response message.




• Records the HTTP Headers.

• View the detailed data ina RAW format (shown) orformatted displaying XMLtags.

Historical Data

• The Historical Data is available for a service or for all services in the organization.Data collected includes: Response time, Usage, Operation Response, OperationUsage and the usage for all Operations of the service or organization




Usage and the usage for all Operations of the service or organization

• Intervals are availableover a number of timeframes up to a month.

• This data can be exported

for archiving to file.

• Data can be viewed in achart or tabular formatfrom the console.

Alert Monitoring

• All Policy Manager components generate alerts in the event of an error conditionor an event (i.e. notification that the alerts have been exported from the databasesuccessfully)




successfully).

• If an alert was generated as a result of an web service request, a correspondingSOAP fault is generally sent back to the consumer at runtime.

• Alert Monitoring can be done from the main Alerts Tab on the Policy Managerconsole, at the Organization level or at the service level.

Alert Summary

• The Alert Summary screen summarizes the total alerts generated for variouscomponents defined within the Policy Manager (including SLA’s)




Alert Monitoring

• The Alert Details page shows information about each alert generated in Policy Managerincluding the alert code, time, severity and component that generated the alert.

• Alerts can be marked as Observed and Resolved and can be used as part of the filter




p

The Dashboard: Service Snapshot

• The Dashboard provides a real-time snapshot of the activity and alerts for adefined set of managed services.




• The services displayed on the Dashboard is user configurable based on varioussets of search criteria.

Creating a Dashboard

• Use the Edit function on the Dashboard screen to create a Dashboard.




• Create a New Dashboard and select thecriteria used to display the services onthe Dashboard.

• Multiple search criteria can beused to display the services.

• The corresponding alerts for theservices selected will be displayed

on the Dashboard.

Auditing Activity in the Policy Manager

• Auditing data is available for both Alert and Security actions

• Alert Audit Trails identifies when alerts have been added modified and deleted




• Alert Audit Trails identifies when alerts have been added, modified and deleted

from the Policy Manager database.

• Security Audit Trails trace all other activity in Policy Manager such as:– When users are added, modified or deleted

– When a service is registered, modified or deleted

– Logins, logouts and invalid logins to the Policy Manager Console

– Key retrieval for users and Policy Manager components

Training Use Case

• Create a Dashboard for all the virtual services in the Policy Manager.

• Send requests to the AccountManager virtual service.




Send requests to the AccountManager virtual service.

• View the activity in the Dashboard.


Policy Manager Migration

Export/Import Capabilities




Export/Import Capabilities

Migrating Between Policy Manager Environments

• Configuration data from different environments (i.e. From Development toStaging) can be migrated using the Policy Manager Export/Import tool.

• The Export Tool allows the exporting of an Organization, Contract and/or Service.




The Export Tool allows the exporting of an Organization, Contract and/or Service.

The data is exported to a file or directory that is referenced during the Importprocess in the “target” environment.

• An import property file can be referenced to facilitate mapping the URL’s andNetwork Instance names from the source environment to the target environment.

Source Policy Manager

ExportTool

ExportFile/

Directory

Development Environment

ImportTool

ExportFile/

Directory

Staging Environment

ImportProperties

file

Target Policy Manager

Export and Import Functionality in Policy Manager




The Export andImport functionalityis supported forOrganization, Serviceor Contract objects

Export Options

• Options are available to select the objects to include in the Export.

• There are some objects that are not exported and need to be recreated in theTarget environment:




g

– Network Director Containers– External Domains

Import/Export Checklist

Determine objects to export from the source environment

Create a property file for the target environment mapping the source and target




Create a property file for the target environment mapping the source and target

URLs and Network Director containers

Export objects from the source environment

Prepare the target environment, manually creating the objects that are not exported

Modify the target environment workflow to reflect the workflow changes requiredfor imported services and contracts.

Import objects into the target environment referencing the property file

Import Property file

• The import file allows mapping between source and target endpoints and sourceand target Network Director containers.




• An example of the import property file is displayed below:

migration.container.source.d138f491-7683-4ade-9b73-777b5584=container1

migration.container.target.e1332471-3683-43de-9b73-6e7b55d4=container1

migration.container.source.a1d8f231-9883-46de-9693-57b5e84=container2

migration.container.target.d138f491-9232-6ac2-6734-87eb584=container2

migration.url.source.http\://box-9\:80=source1

migration.url.target.http\://iisservices\:80=source1

migration.url.source.http\://10.1.20.147\:8080=source2

migration.url.target.http\://host1\:80=source2

migration.url.target.http\://host2\:80=source2

migration.jms.destination.source.jms/ndoutq = dest1migration.jms.destination.target.jms/ndimportout1 = dest1

Source to Target Container MappingContainers are referenced using theContainer Key.

Source to Target URL Mapping

Mapping a single source URL tomultiple target URLs

Mapping JMS destinations

Service and Contract Workflow to Support Importinginto a new environment

• If the default Policy Manager workflow is being used, all services imported intothe target environment are imported in an “In Staging” state.




• Imported contracts are in imported in a “Draft” state.

• The @ImportContract or @ImportService initial action in each respective workflowdocument is modified accordingly to update the workflow configuration for theimported objects.


Maintenance and Troubleshooting Tips




General Troubleshooting Tips

• Check the Policy Manager Monitoring and Alert Data for any system or servicealerts




• Enable the Detailed Auditing Policy if appropriate

• Check the instance log file for more detailed information

• If required, enable debugging for the instance from the Admin console

• Send the log file and update information to [email protected]

Log files and debugging

• Each instance writes a log file into the ./sm60/instances/<instance_name>/logdirectory




• A new log file is created when the file size reaches 5MB.

• By default the log files are set to log only errors

• Debugging/trace can be enabled on an instance through the Admin console forthat instance (i.e. http://<PM_Host>:<PM_Port>/admin/ orhttp://<ND_Host>:<ND:Port>/admin/)

• The logging properties are updated at run time and the log files will reflect thenew log level.

Admin Console Logging Properties

• Logging properties are set from the Configuration Tab of the Admin console.

• Set the log level in the com.soa.log configuration category.





Support




Contacting Support

• Email: [email protected]

Please make sure the priority of the issue is stated when either an email is sent ora ticket is opened from the support site. A ticket number is assigned upon receipt






of the email or submission of the ticket and a confirmation email is sent.

• Support website at: http://www.soa.com/support

• Please provide as much information as possible regarding the issue, includingupdates installed, log files.

• The support website contains:

– Software Downloads (new releases and updates)

– Knowledgebase

– Newsletters

– All your open/closed support tickets

– Ticket Reports

Support Site Navigation

http://www.soa.com/support

http://www.soa.com/support




Support Site Ticket Reporting

• Tickets can be filtered based on Status and exported to a CSV file if required.





Question and Answers



Survey

6.0_PM_Training_Core_V1.1 (1).pdf

Documents

Transcript of 6.0_PM_Training_Core_V1.1 (1).pdf