What is Data Power ?

• Data power SOA Appliance is a purpose built

easy to deploy network devices that simplify,
help secure and accelerate XML and Web
services deployments while extending SOA
infrastructure.
 What is SOA ?

• Service-oriented architecture (SOA) is a

software design methodology based on
structured collections of discrete software
modules, known as services, that collectively
provide the complete functionality of a large or
complex software application
 What is XML ?

• Extensible Mark-up Language (XML) is a

mark-up language that defines a set of rules for
encoding documents in a format that is both
human-readable and machine-readable.
 What is XSLT ?

• XSLT (Extensible Stylesheet Language

Transformations) is a language for transforming
XML documents into other XML documents, or other
objects such as HTML for web pages, plain text or
into XSL Formatting Objects
 What is Xpath ?

• Xpath, the XML Path Language, is a query

language for selecting nodes from an XML document.
In addition, Xpath may be used to compute values
(e.g., strings, numbers, or Boolean values) from the
content of an XML document
 What is WSDL ?

• The Web Services Description Language is an

XML-based interface description language that is
used for describing the functionality offered by a web
service. The WSDL describes services as collections
of network endpoints, or ports
 What is SAML ?

• Security Assertion Markup Language (SAML) is

an XML-based open standard data format for
exchanging authentication and authorization data
between parties,
 SOA specifications based on XML
• XML Schema : Describes the structure of an XML document
using an XML syntax.

• SOAP : provides a standard structure for web services requests

and response messages in XML format.

• WSDL : Provides a language for defining the interface and

binding details of a web service. WSDL documents are XML
documents.

• XSLT : The language for transforming XML documents to

another format. Transform templates are described using xml.
• Xpath : A platform independent syntax for addressing
parts of an XML document tree.

• XML digital signatures : provides a standard for storing

digital signatures of XML documents in XML format.

• XML encryption : provides a standard for string

encrypted parts of an XML document in XML format.

• SAML : Provides a standard for stating security

assertions. Assertions can be written in an XML format.
 IBM Web sphere Data power Product Line
• Websphere Datapower XML Accelerator XA35 – It offloads
processor intensive XML Processing and transformation tasks
from application servers.

• Websphere Datapower XML Security Gateway XS40 – It

acts as a security policy enforcement point for XML
applications and web services.

• Websphere Data Power Integration Appliance XI50 -

provides ESB functionality, bridging protocols and performing
any – to- any transformations.

• Websphere Datapower B2B Appliance XB60 – Purpose built

B2B hardware providing AS2 and AS3 messaging.
 XML Accelerator XA35 features

• Accelerate dynamic content generation

Transform XML data into any presentation layer format at wire
speed

• Offload XML manipulation through industry standard API

Perform XML processing and transformation on XA35 through
the Java API for XML Parsing (JAXP)
 XML Security Gateway XS40 features
• XML and Webservices security provides :
• Field level message encryption and digital signature.
• webservices access control at the operation, interface, or
endpoint level.
• Service virtualization to abstract service endpoints within
your network
• Authentication, authorization and auditing (AAA) framework
supporting a variety of user password, security token, and
other identity information from requests.
• Service level management, policy management, and
webservices management support.
• includes all XML acceleration features from XA35 appliance.
 Integration Appliance XI50 features
• Processor intensive tasks such as XSLT processing, routing,
and legacy-to-xml conversion can be offloaded to the XI50.
• XML-to-any conversion allows mainframe applications to be
virtualized as web services.
• Parse and transform arbitrary binary, flat text, and xml
messages.
• No custom programming needed to manipulate messages.
• XI50 appliances acts as an IBM Websphere MQ client.
• includes all security and acceleration features from the XS40
and XA35 appliances respectively.
 Websphere Datapower Low Latency XM70

• Low Latency Messaging (LLM) appliance for high throughput

messaging.
• High speed message routing and filtering.
• Optimized to bridge between leading standard messaging
protocols such as Websphere MQ, Tibco, Websphere JMS,
HTTP and HTTPS
• Simplified deployment, configuration, and management
providing rapid configuration of LLM- based applications
• Govern low latency multicast and unicast messaging through
consolidated processing point.
 Websphere Datapower B2B appliance XB60
• Purpose built B2B gateway for simplified deployment and
hardened security.
• Extend integration beyond the enterprise with a securely
deployed B2B gateway in the DMZ.
• Easily manage and connect to trading partners using industry
standards.
• Improve the performance and scalability of B2B interfaces .
• Govern B2B integration points through consolidated trading
partner management.
 Datapower SOA appliance administration

• Can perform administration tasks on the Datapower

SOA appliance by using one of the following
interfaces:

• Web GUI web application.

• Command line interface (CLI)
• SOAP based XML Management API
 Datapower Appliance

4
 Datapower Appliance

1) The navigation bar provides access to configuration or

management options.
2) The control panel allows quick access to common
administration functions. The services section allows you to
create or modify the primary Datapower services.
3) The monitoring and troubleshooting section provides a view
of the Datapower SOA appliance status, traffic and load.
4) The files and administration section manages the
configuration files, access levels, and cryptographic keys
and certificates on the appliance.
 File directories for configuration
• Config: Stores configuration files for the current application
domain.

• export : Holds any exported configuration created with the

Export configuration operation.

• local : stores files used by local services, including XML style

sheets, XML schemas, and WSDL documents.

• store : Stores sample and default style sheets used by Data

power services.

• temporary : Temporary disk space used by document

processing rules and actions.
 File directories for Security

• Cert : Location for storing private keys and digital

certificates.

• sharedcert : stores digital certificates to be shared with

partners

• pubcert : provides security certificates for root certificate

authorities, such as ones used by web browsers.

• logtemp : Default location of log files, such as the system-

wide default log.

• log store : Long term storage space for log files.

File directories for configuration & Security
 Administrative Access Control
• Application Domains: provide a virtualized, enclosed environment for
services. Only the default domain allows administrators to perform system
level tasks, such as configuring an Ethernet service.
• User groups: apply a specific access policy to a set of user accounts
 Privileged access allows users to perform system level tasks.
 User access provides read-only guest access
 Group-defined relies on a user-defined, fine-grained access policy for
each resource.
• User Accounts: provide users with access to the web GUI administration
console.
 Administrator by using the command-line interface

• The command –line interface (CLI) provides a text terminal

for administering the Datapower SOA appliance.
• CLI allows you to configure every service and interface
available in the Datapower SOA appliance.
• In the initial setup you must enable web GUI application and
Ethernet ports with the CLI through a serial connection.
• Administrators have the option of enabling the CLI over a
telnet or Secure shell (SSH) connection.
 Services available on the Datapower appliance

• XSL Proxy – Accelerate XML processing such as schema validation and

XSL transformations.
• XML firewall – Secures and offloads XML processing from back-end-
XML based applications.
• Web services Proxy (WS-Proxy) – Virtualizes and secures back end web
service applications. Supports XML encryption, XML signature and AAA
• Web application firewall (WAFW) – Secures and offloads processing
from web based applications. Threat mediation, AAA, and web- based
validation.
• Multi-protocol gateway (MPG) – Receives messages from clients using
multiple protocols and sends messages to backend services over many
protocols.
• Supports XML encryption, XML signatures and AAA
 XSL Proxy Service

• Validating XML messages using XML schema files.

• Performing XSL transformations
• Communicating with client and back-end servers using SSL
• Monitoring messages passing through the appliance.
• Monitoring and logging activity, delivering log information to
external managers.
• Available on the XA35, XS40 and XI50
 XML Firewall Service

• Secure and offload processing from back end XML based

applications with the XML firewall service
• Ensures document legitimacy by providing tamper protection
using XML signatures.
• Protects against XML-based attacks.
• Secures messages using XML encryption.
• Provides dynamic routing of XML documents to the
appropriate back end service.
• Access control is based on user credentials in the message.
• Supports all the features of the XSL Proxy.
 Web service Proxy Service

• The web services proxy (WS-Proxy) is used to secure and

virtualize multiple back end web service applications.
• WSDL based configuration.
• policies, monitoring and logging can be done at various levels
of the WSDL file.
• Policy can be updated constantly when back end WSDL
changes.
• Features are a superset of the XML firewall
• Available on the XS40 and XI50
 Multi-Protocol gateway service

• A multi protocol gateway connects client requests sent over

one or more transport protocols to a back end service using the
same or a different protocol.
• Single policy applied to multiple messages over many
protocols.
• uses static or dynamic back end protocol and URL
• Features are a superset of the XML firewall
• Available on the XS40 and XI50
 Web Application Firewall Service

• A web application firewall is used to secure and offload

processing from web based applications
• proxies back end web applications by listening for requests on
multiple Ethernet interfaces and TCP ports.
• Provides threat mediation, AAA, and SSL
• Limits the number of requests or simultaneous connections to
backend web applications.
• No document processing policy.
• Customized XML firewall for HTTP – based traffic.
• Available on the XS40 and XI50
 Message Processing Phases

Each message passes through three phases:

• Client-side
 Listen for IP address or port, ACL, SSL, attachment
processing, URL rewrite, HTTP header injection and
suppression and monitors.
• Service Policy
 Service traffic type (SOAP, XML, preprocessed,
unprocessed), XML manager, SOAP validation.
• Server-side
 Streaming URI propagation, user agent, and SSL, load
balancer, HTTP options.
 Basic architectural model

• One appliance has many services.

• Each service uses one policy.
• Each policy references multiple rules.
 Three types of rules: error, request, response.
• Each rule contains multiple actions.
 some standard actions are Validate, Transform,
Results, and more
 Custom XSLT always available using the
Transform action.
 Processing Policy

• A service defines a single policy

• The policy is enforced through rules.
• Each rule contains match action
• Defines criteria to determine if incoming traffic is processed
by the rule.
• processing actions:
• A rule defines one or more actions taken on the submitted
message.
Processing Policy
 Processing rules

• Rules have the following directions:

• server to client (response)
• Client to server (request)
• Both directions (request and response)
• Error : Executes when errors occur during processing in the
request and response rules
• Multiple rules may match on same URL;
• specific rules should have higher priority than catch all rules
Processing rules
 Match Action

• A Match action allows you to provide different processing

based on matching conditions.
• Matching criteria can be based on :
• Error Code value
• Fully qualified URL
• Host
• HTTP header value
• URL
• XPath expression
 Multistep Scope Variables
There are four special system context variables:

• INPUT:
 Data entering the processing rule.
• OUTPUT:
 Data exiting the processing rule
• PIPE:
 Identifies a context whose output is used as the input of the next action.
• NULL:
 When used in output context, silently discards any data generated by the
action.
 when used in Input context passes no message to the action. Such empty
input can be useful when executing a style sheet that does not require input.
 Service Types

• Static Back-end forwards traffic to a statically defined

endpoint.
• Dynamic back-end forwards traffic based on the execution of
a policy, which specifies the back-end host address and port.
• Loopback proxy does not forward the message to a back-end
service once processing is complete. This service type is often
useful for validation and transformation services.
 URL rewriting
• Create a URL rewrite policy to rewrite some or all of a client URL.
• Create a URL rewrite rule
• specify expression to match URL
• Define replacement expression.
 XML Manager
• The XML Manager obtains and manages XML documents, style sheets and
other resources behalf of one or more services.
 All services use the default XML Manager object.
 Accessed from objects XML Processing  XML Manager.
• An XML Manager does the following:
 Set manager associated limits on the parsing of XML documents.
 Enable document caching
 Perform extension function mapping.
 Enable XML manager based schema validatior.
 Schedule an XML manager initiated processing rule.
 Create an XML Firewall

• select an XML Firewall icon in the Data power Control Panel

• Use the ADD Wizard button to create the XML Firewall
• Built-in context variables in policy rule

INPUT: Original document retrieved at start of the

processing rule.
 OUTPUT: Document returned to client.
 NULL: Empty document.
 Processing Actions
• The Encrypt and Decrypt actions are used for XML encryption. The Sign
and Verify actions are used in XML Signatures.

• The advanced actions are:

 Anti-Virus: This action scans a message for viruses using an external
ICAP server.
 Call Processing Rule: This invokes a named rule; Processing resumes
on the next step
 Conditional: This selects an action for processing based on an XPath
expression
 Convert Query Params to XML: This converts non-XML-CGI-
encoded input (an HTTP POST of HTML form or URI parameters) into an
equivalent XML message
 Crypto Binary: This performs a cryptographic operation (Sign, Verify,
encrypt, decrypt) binary data.
 Event-sink: This forces a wait for asynchronous actions before
continuing.
 Extract Using XPath: This applies XPath expression to a context and
stores the result in another context or a variable.
• Fetch: This retrieves an identified external resource and places the result in the
specified context.
• For-each: This defines looping based on a count or expression.
• Header Rewrite: This rewrites HTTP headers or URLs.
• Log: This sends the content of the specified input context as a log messages to the
destination URL identified here.
• MQ Header: This manipulates MQ Headers.
• On Error: This sets a named rule as the error handler; it is invoked if subsequent
processing encounters errors.
• Results asynchronous: This asynchronously sends a message in a specified
context to a URL or to the special output context.
• Route (Using Variable): This routes the document depending on the contents of a
variable.
• Set variable: This sets the value of a variable for use in subsequent processing.
• SQL: This sends SQL statements to a database.
• Strip attachments: This removes either all or specific MIME or DIME
attachments.
• SLM Rule: This invokes an SLM (service level monitor) policy
• Transform (using processing instruction) : This transforms by using XSLT that is
specified by processing instructions within the XML document; the parameters may
be passed.
• Transform Binary: This performs a specified transform on a non-XML message,
such as binary or flat text.
 Troubleshooting Panel
The Troubleshooting page contains the following tools
• Ping Remote
 Ping a remote host address
• TCP Connection Test
 Create a TCP connection to remote endpoint.
• Packet Capture (default domain only)
 Captures network packets to and from the appliance
• View System log and generate log messages
 Specifies log level of messages to record
 Generates log messages for testing log targets
• Error Report
 Includes the running configuration and relevant system log entries for
errors
 E-mails error report to an e-mail address.
• XML File Capture (default domain only)
 Captures inbound XML files submitted to the appliance
• Probe
 Enables or disables probes on services.
 Send a test message
• Builds a SOAP request with a customized header
content and body that is used for testing
• A URL can be generated using the different
helpers
• Request headers can be added
• A request body can be typed or pasted here
• The response is displayed here
• Control Panel > Administration > Debug > Send
a test message
 System log

• Displays system wide log messages generated by the

appliance
• Click the view logs icon in the control panel
• In the troubleshooting panel, scroll down to the
logging section
• Click view system logs
• By default, log messages are only captured with
severity of notice or greater
• Log levels are hierarchical
• Highest severity (emergency) is at the top of the list
• Each level captures messages at or above the current
level
• To enhance troubleshooting, set the log level to
debug
• Lowest severity (debug) captures the most
information.
 Filtering System log

• Filter the system log by:

• Log target
• Domain
• Data power objects (xml firewall, ws-proxy, and
more)
• log level type (debug, info, and more)
 XML File Capture
• Captures XML messages from any service
• XML messages that services cannot parse can also be
captured
• File capture can fill the available storage space
• Files are cycled FIFO
• Maximum of 5000 files or 200 MB can be captured
• stored in compressed format
• XML file capture should only be enabled in test
environments
• Default domain only
 Logging basics
• Logging System is based on the publish/subscribe
model
• objects publish events
• Subscribers subscribe to events of interest.
• The Data power logging system uses log targets as
subscribers and log events (generated by objects) as
publishers.
• Logs can be written on-device or off-device.
• On-device logs can be moved off-device (SFTP, SCP,
HTTP,
 Available log levels
• List of log levels for the system log:
• Emergency – system is unusable
• Alert – Action must be taken immediately
• Critical – Critical condition
• Error – An error has occurred. The error code is included.
• Warning – A warning condition has occurred. Nothing may
be wrong, but conditions indicate a problem may soon if
nothing changes.
• Notice – A normal but significant condition applies
• info – An informational message only
• Debug – Debug – level messages. This level generates a lot
of messages.
 Log Targets
• Log targets subscribe to log messages posted by the
various running objects.
• Create a log target by selecting Administration >
Miscellaneous > Manage Log Targets
• These log targets subscribe to certain types of events
that are generated or published by objects on the Data
power appliance.
• Use the Generate log event tool in the
troubleshooting panel to test if log messages are
captured by log targets
 Log Target configuration

• Configuring Log target tabs

• Main – Target type
• Event Filters - Can restrict messages by event code
• Object Filters – Can restrict messages that appear in
a target by object
• Event subscriptions – Subscribed to event
categories or object class
• Categories have a priority level
• Log target needs to subscribe to at least one event
category
 Nine Log Target Types
• Cache – Writes log entries to system memory
• Console – Writes log entries to a Telnet, SSH, or CLI
screen
• File – Writes log entries to a file on the device flash
• NFS – Writes log entries to a file on a remote NFS
server
• SMTP – Forwards log entries as SNMP traps
• SOAP – Forward log entries as SOAP messages
• Syslog – Forwards log entries to a remote Syslog
• Syslog-ng - Forwards log results to a remote Syslog
 Log Action
• The log action send the contents of the input context to a
destination URL
• Used to log entire message instead of creating a log entry
• configure the following
• Destination – Must be a valid URL to either a local file or
remote destination
• Log Type – Log priority
• Log Level – Event Category
• If no output context is specified the log action sends the
contents and does not wait for a response

• An output context should be specified be specified on the log

action if the policy administrator wishes the failure of the log
action in a policy rule to cause an error condition in the
processing of the rule.
 Error Handling Constructs
• Two methods for handling error:
• On Error action
• Provides the ability to either abort or continue
processing
• If continue then the next action in the rule is
executed; otherwise the rule is aborted
• Error rule
• Automatically executes if it is configured within the
current document processing policy
• Presence of an On Error action precludes the
automatic selection of an error rule for execution
 Configure an On Error action
• The On Error action is used to control what happens
when an error is encountered within the rule
• Optional : Execute a named rule to handle the error
condition
• Configure the following within an On Error action
• Error mode:
• Cancel: Stop executing the current rule
• Alternative: Invoke an alternative processing rule
• Continue: Continue with the next sequential action
• The processing rule fields specifies either of:
• an error rule to execute
• A custom variable for the processing rule
• Use the Var Builder to create a custom variable
 Error rule versus On Error action
• The presence of the On Error action precludes an error rule
within the same service policy from being selected to handle
error
• On Error action itself can optionally execute an error rule
• The error rule executes in the absence of an On Error action
when an error occurs in the current processing rule
• The current processing rule is aborted and the execution of the
error rule starts
• Multiple On Error actions can be defined in a processing rule
• Each On Error action handles errors for subsequent actions
within the same processing rule
• When the next On Error action within a rule is executed it
handles errors for the next set of actions.
 Security Problems
• Message Confidentiality – How do you
prevent anyone from looking at your
message?

• Message integrity – How do you know if

anyone has looked at the message and
changed it ?

• Nonrepudiation - How do you know who the

party on the other end is ?
 Message Confidentiality
• Study of techniques used to transform information
into an unreadable format called a cipher
• Only the party for whom the information is intended
can decipher the message
• Modern cryptography uses algorithms and keys to
manipulate data
• PKI public key infrastructure uses the processes of
encryption to hide a text message and decryption to
recreate the message
 Symmetric Key Encryption
• A secret key that is used to both encrypt and decrypt
messages
• known only by sender and receiver
• relatively fast
• challenges – Exchanging keys with many people
• The disadvantage of symmetric keys is that the same
key is needed for encryption and decryption and both
parties must have the same keys

Encryption Decryption
plain text cipher text plain text
 Asymmetric Key Encryption
• Two keys
• Public key: Published keys known to everyone
• Private key : Secret key known only by the recipient

• The cryptographic process uses keys

• Encryption: The process of applying a key to create a
cipher text message
• Decryption: When an a key is applied to a cipher text to
recreate the original message

Public key Private key

plain text cipher text plain text
 Message Integrity

• A cryptographic hash function is an algorithm that

transforms a string of characters into a shorter
number of a fixed length. This value is called the
message digest

• The cryptographic hash computes a message digest

or message authentication code (MAC) which is
unique to that message
 Non Repudiation
• Digital signatures provide the ability to authenticate
who sent the message
• provided within a digital certificate
• Incorporates the use of asymmetric keys and
cryptographic hash functions

• The digital signature is

• Encrypted with the senders private key
• verified when the certificate is checked
 Digital Certificates
• The problem with public private key pairs is that they do not identify
anyone
• Given a message encrypted or signed using a private key you can
determine which public key goes with it but so what?
• The solution is digital certificates
• A special kind of public key
• Contains your identity information in the form of a distinguished name
• A digital certificate contains:
• The certificate holders name
• A serial number
• Validity dates
• A copy of certificate holders public key
• A digital signature to verify that the certificate has not been altered since
it was altered by the issuer
• An indication of the issuer of the certificate the “the trusted signer”
• A digital certificate does not contain the private key although the private
key and certificate together are often referred to as the certificate
 Crypto Profile

• Identifies profiles that can be used in SSL

connections
• SSL server profile will have an identification
credential private and public key pair and maybe a
validation credential
• SSL client profile will have a validation credential
 SSL Features
• SSL Provides
• Message Confidentiality - uses asymmetric and symmetric key
encryption
• uses a handshake when initiating contact
• the handshake establishes a session key and encryption algorithm between
both parties prior to any messages being sent

• Message integrity – Uses the combination of shared secret key and

cryptographic hash function
• Ensures that the contents of any messages are not modified

• Mutual authentication – Server always authenticates to client

• Client optionally authenticates to server
• occurs during handshake
 SSL Terminology
• cipher spec is a combination of:
• A cryptographic hash function used to create the message digest or
message authentication code (MAC)
• Encryption method algorithm
• Encryption method algorithm + hash function = Cipher spec

Cipher suite is a combination of:

Cipher spec
Authentication-key exchange algorithm
Cipher spec + authentication key exchange = cipher suite
 Securing connections from client to appliance

• To set up SSL between client and appliance you need to perform the
following:
• Data power appliance needs to supply a cryptographic certificate
• Matching private key for certificate is maintained by appliance
• Configure an SSL server crypto profile with cryptographic objects linking
to certificate key pair
• verify the settings in the SSL proxy profile
• Client will validate the certificate presented by the appliance
• Appliance may request a certificate from client and validate
• Appliance may use certificate authority certificates to validate client
Verify SSL server proxy profile settings

• An SSL proxy profile is automatically created when you

specify an SSL server crypto profile
• In the vertical navigation bar expand objects and select crypto
> SSL proxy profile
• In the configure SSL proxy profile list page click the newly
created SSL proxy profile
• The reverse crypto profile is automatically populated
 Securing the connection from appliance to external
application server

• To set up SSL between the appliance and an external

application server we need to perform the following:
• The Data power appliance needs to validate the certificate
supplied by the external applications server
• The list of certificates used to validate is stored on the
appliance
• The application server contains a matching private key for the
certificate
• Configure an SSL client crypto profile with cryptographic
objects linking to validation credentials
 User agent

• user agents communicate with the backend service

• Policies are applied using a URL match expression
• Multiple policies can be associated to a user agent
and triggered based on different URL strings
 Configuring a user agent
• The XML manager default object uses a default user agent
• In the main tab enter the user agent name and set HTTP
settings
• Techniques to set up communication
• Proxy policy: specifies a URL match expression to forward to
a remote address and port
• Basic authentication policy: Associates a user name and
password with a set of URLs
• SOAP action Policy: Associates a SOAP action HTTP header
with a set of URLs
• Public key authentication Policy : Associates a specific private
key to use during public key authentication.
 AAA
• Authentication: Verifies the identity of the
request sender

• Authorization: determines whether the client

has access to the requested resource

• Auditing: keeps record of any attempts to

access resources
 Authentication and Authorization
Framework

• First step: The style sheet extracts the identity

token from the message. To verify the claims
made by the token the style sheet either
authenticates the token against an on- board
policy or queries an external control server.
• Second Step: The style sheet extracts the requested
resource from the message. A resource represents a
service or service operation.
• Once the style sheet determines the requested back
end resource and confirms the clients identity, it
decides whether the client has permission to access
the requested resource. It means back end.

• Final Step: It is auditing and accounting. The style

sheet records any access attempts, successful or
unsuccessful for monitoring.
 Access Control Policy

• Define one or more identity extraction methods

• Define the authentication method
• Map authentication credentials (optional)
• Define resource extraction methods
• Map requested resources (optional)
• Define the authorization method
• Specify post-processing actions (optional)
 Authorize authenticated Clients
• The client communicates to the Data power SOA
appliance over a Secure Socket Layer (SSL)
connection
• A WS-Security username Token element holds the
requesting client identity
• Verifies the claimed identity of the client against a
list stored on the Data power SOA appliance
• The requested resource is the web service operation
• Allows any authenticated client access to the web
service operation.
 Identify the Client

• Create a new AAA policy object on the Data power

SOA appliance
• Extract the clients identity using password-Carrying
Username Token Element from WS-Security Header
option
• For the authentication method, Use Data power AAA
info file
• Specify the name of the AAA information file in the
URL field.
• Leave the identity mapping method at none
 Authorize access to resources

• Select Local name of request element as the

resource extraction method
• Leave the resource mapping method at None
• For the authorization method allow any
request from an authenticated client to proceed
 Security token conversion

• The client communicates to the Data power SOA

appliance over a Secure Sockets Layer (SSL)
connection
• The HTTP BASIC AUTH header information holds
the identity of the requesting client
• Generates a WS-Security Username Token element
corresponding to the HTTP BASIC-AUTH header
• Defers the authentication and authorization tasks to
the back-end web service
 Identify the Client

• Create a new AAA policy object on the Data power

SOA appliance
• Extract the clients identity using the HTTPs
Authentication header option
• For the authentication method specify pass Identity
Token to the Authorize step
• Leave the identity method at none
 Authorize access to resources

• Select Local name or request element as the

resource extraction method
• Leave the resource mapping method at none
• Set the authorization method to Always Allow
requests
• In the post processing step Add WS-Security
Username Token
Lightweight Third Party Authentication
• Lightweight Third Party Authentication (LTPA) is a single
sign (SSO) credential format for distributed, multiple
application server environments
• LTPA is a proprietary token type used by the IBM Web
sphere Application Server and Lotus Domino products
• propagates the caller identity through a unique identifier of
the client
• Establishes a trust relationship between two servers with
one as the client and one as the server through a signed
token.
• keeps the information within the token secret by signing
and encryption the token
• A set of key files must be uploaded to the Data Power SOA
appliance to decrypt and validate the digit signature within
the token
 SAML
• SAML: Security Assertion Mark up Language
• SAML provides an XML based framework for exchanging
authentication, authorization and attribute assertions between
the entities
• This language provides a standard platform neutral way for
exchanging security information between a security system
and an application that trusts the security system
• Expands the authentication and authorization trust model from
existing systems by allowing new systems to delegate trust
management to other systems
• Includes protocol for requesting this information from
security authorities
• Example : SOAP
 Types of SAML assertions
• Three main types of XML based SAML assertions
exist:
• Authentication assertions represent the identity
of the specified subject verified by another
entity
• Attribute assertions represent any attributes
associated with the specified subject
• Authorization decision assertions represent
whether the specified subject has been granted
or denied access to a specified resource
 Authorize Valid SAML assertions
• Create an access control policy that handles client
SOAP web service requests with the following
conditions
• A SAML authentication assertion holds the
requesting client identity
• Accepts the claimed identity of the client if the
digital signature of the SAML assertion is valid
• The requested resource is defined as an attribute in
the SAML assertion
• Allows any authenticated client with a specific
SAML attribute access to the web service operation.
 Identify the client
• Create a new AAA policy object on the Data power SOA
appliance
• Extract the clients identity using the Name from SAML
authentication assertion option
• For the authentication method, select Accept a SAML
Assertion with a Valid signature
• Leave the identify mapping method at none
• select Local name of request element as the resource
extraction method
• For the authentication method use SAML attributes from
authentication
• Set SAML Attributes from the authentication method page
 Match SAML attributes
• In the SAML Attributes page click Add
• Declare the expected SAML attribute values within a
SAML attribute statement
• The namespace URI and local name represent the
qualified name for the SAML attribute
• The attribute value is application specific it can be
used to represent the identity of the client or the name
of a requested resource
 Access control policy using SAML information
• Identity extraction methods:
• Name from SAML attribute assertion <saml: subject> element
• Name from SAML authentication assertion <saml : subject>
element
• SAML browser artifact from the URL query string

• Authentication methods:
• Accept a SAML assertion with a valid signature
• Retrieve SAML assertions corresponding to a SAML browser
artifact
• Contact a SAML server for a SAML authentication statement

• Authorize methods:
• Generate a SAML authorization query
• Generate a SAML attribute query
 LDAP
• LDAP : Lightweight Directory access protocol
• It is a networking protocol for communicating with directory
services over TCP/IP
• The LDAP protocol allows the storage and retrieval of
information on people, groups or objects from a centralized
X.500 directory server
• Based on the client/server model of computing
• X.500 enable information to be organized and queried using
LDAP from multiple web servers using a variety of attributes
• LDAP reduces system resources by including only a
functional subset of the original X.500 Directory Access
Protocol (DAP)
 LDAP operations

• Each LDAP message contains the operation (bind,

update, delete) requested by the client
• Authentication
• A bind operation authenticates the client by sending the
client distinguished name and password in clear text
• Uses an SSL connection to keep LDAP queries secret
• an anonymous bind resets the connection to an
anonymous state
• Default access rights
• Search: Specifies criteria used to return matching
entries
• Compare: uses the DN and attribute name – value
pairs to check whether the DN entry contains that
attributes name- value pairs
• Update consists of add, delete and modify operations
• Add: inserts new entries into the directory
• Delete: Removes only leaf nodes from directory
• Modify: Add, update or remove attributes or attribute
values for an entry
 Authenticate the client using LDAP
• Set Bind to specified LDAP Server as the
authentication method
• Bind to the LDAP server specified in the Host and
port settings or the Load Balancer Group
• Set the Bind DN and Bind Password for an LDAP
query
• Use the Search Attribute fields to verify the
password digest from a WS-Security username token
• Use the prefix and suffix fields to build an LDAP
query
 Authorize the client using LDAP

• Bind to the LDAP server specified in the Host and port settings
• select or create an SSL Proxy profile
• Specify the Group DN of which the identity is a member
• Set the Bind DN, Bind Password for an LDAP query
• Use the Load Balancer Group to specify a cluster of LDAP
servers
• The LDAP Group Attribute is a string used to check for
membership in the Group DN of the identity
• The LDAP Search Scope and LDAP Search Filter are used to
refine the search in a LDAP query.
 SLM
• SLM – Service Level Monitoring
• SLM is the process of measuring service quality
• Performance and availability relative to customer
expectations
• Reporting results and taking action ensure the quality
stays within agreed upon parameters defined by SLA
(service Level Agreement)
• Incoming traffic is filtered based on predefined criteria
• Policy is applied to selected messages
 SLM in Data Power
• Service-level monitors (SLM) : Allows administrative
control over users and resource groups
• SLM Policy : Consists of one or more statements consisting
of restrictions
• Action can be taken when a restriction is violated
• An SLM is implemented by an SLM policy
• SLM Statement : Counts messages or measures message
execution duration
• Statements are processed sequentially in the order they are
configured
• SLM policy consists of one or more statements
 Two Ways to configure SLM
• Method 1: During the configuration of a document processing
policy
• The SLM Rule action is configured as part of the document
policy
• In the web service proxy the SLM Rule action is a separate
icon in the policy editor
• In the multi protocol gateway, the SLM rule action is selected
from the advanced tab

• Method 2: From the object/Monitoring menu option

• All the basic SLM objects are first configured and then SLM
policy is constructed from these basic components.
SLM types in the Web service proxy
• There are six service level monitor types
• Global SLM : Monitors all transactions in the Web Service
Proxy
• WSDL – specific monitor : Monitors all services described in
a specific WSDL file
• Service-specific monitor: Monitors a single web service
• Port-specific monitor : Monitors a single web service port
• Operation specific monitor : Monitors a single web service
operation
• Custom SLM : provides fine grained control over monitored
transactions
 The WS-Proxy SLM Tab
• Configuring a SLM Policy from the SLM tab specifications
• Under Request, we can count the number of transactions that
occur with a specific interval; and if the transaction limit is
exceeded we can specify an action to:
• Notify : This generates a log message if the transaction limit is
exceeded
• Throttle: Additional transactions above the limit is exceeded
• Shape : The first 2500 transactions in excess of the maximum
transaction rate are queued for later transmission and
subsequent transactions in excess of the 2500 limit are dropped
• Under Failure, you can specify the same information as
Request, except that these settings apply to error messages
 SLM Rule Action
• An SLM Rule action selects an SLM policy for execution
• WS-Proxy : The SLM Rule action has its own icon
• MPG : The SLM Rule action is selected from the Advanced
icon

• An SLM policy enforces a set of actions to take when

configured traffic thresholds have been reached

• The document processing policy must have an SLM Rule

action configured in the appropriate rule to activate the SLM
Policy
 Constructing an SLM Policy
• Configuring an SLM policy from the ground up
requires that the dependent objects be defined
• An SLM Policy requires the following objects to be
constructed if they affect the policy:

• SLM credential class

• SLM resource class
• SLM schedule
• Specification
• SLM Action
 SLM Credential Class
• Select Objects > Monitoring > SLM Credential class
• A credential class consists of:
• Credential type
Specifies method used to obtain credential
• Match type
Specifies how a successful match is determined
• Credential Value
It is used to specify exact values when match type is
exact match
• Request header
Name of a header when the credential type is request
header
 SLM resource class
• Identifies a set of resources subject to an SLM policy
statement
Select Objects > Monitoring > SLM Resource class
A resource class consists of :
• Resource Type
Specifies a method used to identity the resource
• Match Type
Specifies how a successful match is determined
• Resource Value
Values to match
 SLM Action
• When an SLM policy statement detects a service level violation, and SLM
action defines the response
Objects > Monitoring > SLM Action

Action Types

• Notify
Creates log message when action is fired
• Shape
Buffers requests to meet traffic threshold up to limit otherwise it will
reject
• Throttle
Reject outright

• New SLM actions can be defined to change log priority of logged message
 SLM Schedule
An SLM schedule specifies a time period during which the
associated SLM policy statement is enforced
select Objects > Monitoring > SLM Schedule

Schedule Elements
• Week Days
Specifies days of the week when the SLM policy is
enforced
• Start Time
Start time is expressed in HH:MM:SS format
• Duration
Number of minutes that the schedule is enforced
 SLM Policy

An SLM Policy consists of SLM statements and an evaluation method

Select Objects > Monitoring > SLM Policy
Evaluation method :

• Execute all statements : This causes the policy to execute all policy
statements regardless of what action those statements take
• Terminate all first action : This causes the policy to stop executing any
statement after the first statement that takes any action.
• Terminate at first reject : This causes the policy to stop executing any
statement after the first statement that rejects a message
 Web sphere MQ Fundamentals
• A queue manager manages a container for messages sent
over a web sphere MQ network
• In a publish/subscribe model, queues represent a message
destination for messages organized in FIFO order
• Queue managers send messages over a communications link
known as a channel
• An MQ client such as FSH must poll the queue manager for
new messages
• The queue manager itself does not initiate connections to the
clients
 Web sphere MQ message
Web sphere MQ message are divided into two parts:

• Message descriptor
contains message ID and control information
• Application data
Message payload
• Data contained within the message descriptor is encapsulated within
an <mqmd> header
Message metadata: contains information about the message
• Application data
Contains application- specific data such as an XML message
 Transactions
• A transaction is a sequence of operations that either commit or
rollback their work
• A transaction rolls back if any one of the operations in the
transaction fails
• A transaction commits if all the operations in the transaction
succeed
• A local unit of work is defined as when only the queue
manager resources are being updated
• A global unit of work is defined as when resources of other
resource managers are also being updated
 Provide Web sphere MQ Access

• The MPGW can be configured to accept requests

from an IBM Web sphere MQ system
• Request and response messages reside in queues on a
web sphere MQ queue manager
• All requests are sent to the back end web service over
another set of web sphere MQ queues
• Web service request messages that pass through the
gateway execute a service policy
 Create an MQ queue manager
• Create a new MQ queue manager object from the
control panel
• Provide the host name or IP address of the queue
manager
• Provide the queue manager name if it is different
from the default
• Provide an alternate channel name if necessary
• Enter a user name that identifies the client to the
queue manager
• Specify whether the MQ queue manager participates
in a transaction
• Set the total number of open connections
• Specify the encryption key and type for an SSL
connection
• Configure an automatic retry interval to
automatically reconnect to the queue manager
 Use SSL in mutual authentication mode
The MQ manager can be configured to use SSL in mutual authentication
mode with a remote web sphere MQ queue manager

Execute the following steps

• Configure the remote web sphere MQ queue manager to use SSL
• In Data power generate a self signed certificate
• Data power generates the certificate/key pair in the PEM format
• Use an external application to convert the PEM format to pkcs12
• This step is required since web sphere MQ does not understand the PEM
format
• Import the converted certificate/key into web sphere MQ
• Obtain the web Sphere MQ key database file and import it into Data power
and select it in the SSL key repository field
 Add an MQ front side handler
• Open the multi protocol gateway
• Create a new MQ front side handler to accept
requests from a web sphere MQ system
• Select the queue manager object that was defined in
the previous step
• Specify the queue for the request messages and the
response messages
• Configure the character code set identifier for the
messages on the queue
Configure an MQ back – end transport
• Click the MQ Helper button in the Back side settings
• Select a new or existing queue manager object
• Set the URI identifying the service on the final back end
destination
• Specify the request and response queues
• Set Transactionality to on if the queues participate in a unit
of work
• Enable the User identifier header field if a processing action
is added an identifier
• Set ReplyToQ to on to copy the reply ObjectName in MQOD
to ReplyToQ in MQMD
MQ Header action in service policy
• In policy editor, Advanced > MQ Header

• Enables manipulation of MQ headers without

requiring a style sheet

• Allows modification of MQMD request headers

MQMD response headers queue manager and reply
queue for response message retrieval by message ID
or correlation ID
 Web Sphere MQ Data Power URL
• The web sphere MQ Data power URL is of the following form
dpmq://QueueManager/URI?RequestQueue=PUTQ;Rep1yQueue=G
ETQ;Sync=true;Transactional=true;PMO=2048

• Queue Manager: Name of the Web sphere MQ queue manager

object
• URI: string to be included in the URL
• Request Queue: Name of the queue where messages are sent
• Reply Queue: Name of the queue to poll fro messages
• Transactional: Used to enforce transactional units of
communication with back side queue managers
• Sync : Used to send MQCOMMIT to back side queue manager
after MQPUT
• PMO: Set options on the MQPUT call
• The URL open extension element supports the web sphere MQ data
power URL
• A style sheet can GET and PUT to queues
 Messaging middleware
• Messaging middleware acts as a broker to provide
asynchronous delivery of data between applications
• Acts as an intermediary between the producer and consumer
of the message
• Ensures reliable message delivery
• Web sphere MQ is an IBM messaging middleware product
• Enterprise Message Service (EMS) is TIBCO’s messaging
middleware product
• Messages are sent to destinations and stored until delivered
• Delivery is managed by the messaging middleware
• Consumer and producer need not be active at the same time
 JMS
• Java Message Service (JMS) is a java API for
accessing messaging middleware
• JMS provides:
• Programming interface – does not provide actual run
time
• Vendor-neutral and standard approach to use
messaging middleware such as Web sphere MQ
• A messaging middleware that supports JMS is known
as a s JMS provider
• J2EE V1.4 and JEEV5.0 require that applications
servers:
• Include a JMS V1.1 provider
• Support JMS 1V.1 to access messaging middleware
 Web sphere JMS Support
• Data power supports JMS messaging to the default messaging
provider in Web sphere application server V6 using the service
integration bus
• Firmware uses the IBM JFAP (JetStream Formats and
Protocols) to communicate with the service integration bus

• Scenario: Send SOAP messages over JMS using the Data

power Web sphere JMS front side handler
• SOAP/JMS web service implementation can read messages
from a JMS queue and put response onto another queue
 Web sphere JMS interaction

• Web sphere JMS object represents the connection to

the bootstrap server on web sphere application server
• Remote web sphere JMS applications are unable to
communicate directly with a messaging engine on a bus
the bootstrap server enables this communication
• The Web sphere JMS Front side handler uses the
web sphere JMS object to communicate with specific
queues
• The back end URL also uses the web sphere JMS
object to manage communication to a back end JMS
service
 Communicating to Web sphere JMS

• The MPGW service supports web sphere JMS as a

front side handler and Back end url
• polls messages from a JMS queue on the front side
• puts response on a reply queue
• sends messages to a JMS queue on the back end
• reads response from a reply queue
• similar to the web sphere MQ support
 Web sphere JMS Back end URL

• The settings in the URL produces:

• dpwasjms://EastAddressSearchJMS/?RequestQ
ueue=BACK.PUT&ReplyQueue=BACK.GET
 TIBCO EMS JMS support
• Data power supports JMS messaging to the
messaging support in TIBCO EMS

• Scenario: Send SOAP messages over JMS using the

Data power TIBCO EMS front side handler

• SOAP / JMS web service implementation can read

messages from a JMS queue and put responses onto
another queue
 TIBCO EMS interaction

• The TIBCO EMS object represents the connection to

JMS in TIBCO EMS

• The TIBCO EMS Front Side Handler uses the

TIBCO EMS object to communicate with specific
queues

• The Back end URL also uses the TIBCO EMS object
to manage communication to a back end JMS service
 Communicating to TIBCO EMS

• The MPGW supports TIBCO EMS as a front side

handler and Back end URL

• polls messages from a JMS queue on the front – side

• Puts response on a reply queue
• Sends messages to a JMS queue on the back end
• Reads response from a reply queue
 TIBCO EMS Back end URL

• The settings in the URL produces

• dptibems://EastAddressSearchTIBCO/?RequestQueu
e=BACK.GET&ReplyQueue=BACK.PUT
 XSL

• Three parts of XSL

• XSLT - Transformation Language
• XPATH – A language for addressing parts of an
XML document
• XSL-FO (Optional) – An XML vocabulary for
specifying formatting semantics
 Using Custom style sheets
• Data power functionality is implemented using XSL style
sheets
• XSL style sheets perform document processing actions
such as Encryption, Routing, and AAA
• other actions such as Transform or Filter, explicitly require
XSL style sheets as input parameters
• Develop custom actions by designing your own XSL style
sheets with Data power extension functions
• Extension functions allow standard XSL style sheets to
access features within the Data power SOA appliance
• Map custom extension functions to Data power extension
functions with the XML Manager
• Only use when the functionality is not provided by the Data
power appliance
• Do not modify built in Data power XSL style sheets
 Data power Variables
• Data power variables are mutable; their value can be
modified after declaration
• create Data power variable
• within a document processing policy using the Set
Variable action
• use and Advanced action to configure as Set Variable
action
• within a style sheet with the dp:set-variable function
• <dp:set-variable name=“var://context/test/port”
value=“2068”/>
• Remember that variable names are strings
• Retrieve the value of a Data power variable using the d
dp:variable extension function
 Style sheet using DP Extension Functions

• <xsl:stylesheet version=“1.0”
• xmlns:xsl=http://www.w3.org/1999/XSL/Transform
• xmnls:dp=http://www.datapower.com/extensions
• xmnls:dpconfig=http://www.datapower.com/param/config
• extension-element-prefixes=“dp”
• exclude-result-prefixes=“dp dpconfig”>
 ESB
• An enterprise service bus (ESB) is a software
architecture model used for designing and implementing the
interaction and communication between mutually interacting
software applications in service-oriented architecture (SOA).
As a software architecture model for distributed computing it
is a specialty variant of the more general client server software
architecture model and promotes agility and flexibility with
regards to communication and interaction between
applications
 ESB
• An ESB transports the design concept of modern operating
systems to networks of disparate and independent computers. Like
concurrent operating systems an ESB caters for commodity services
in addition to adoption, translation and routing of a client request
to the appropriate answering service.
• The prime duties of an ESB are:
• Monitor and control routing of message exchange between services
• Resolve contention between communicating service components
• Control deployment and versioning of services
• Marshal use of redundant services
• Cater for commodity services like event handling, data
transformation and mapping, message and event queuing and
sequencing, security or exception handling, protocol conversion and
enforcing proper quality of communication service