WebService Proxy, Multiprotocol gateway and XML Firewall
Web Service Proxy is a powerful service in DataPower which provides abstraction and security to the backend web services .It provide access to variety of web services.
WSP has many important characteristics like
- WSP is a WSDL Based Configuration
- Parser-based XML threat protection
- XML well-formedness checking
- It has a Tree structure in Processing Policy and we can have processing rules at different levels – Proxy, WSDL, Service, Port and Port-Operation levels
- We Cannot have a loop back mode in WSP
- Match action and Policy will be automatically created
- It can only Handle SOAP based message format
- URI abstraction
- Schema Validation
- Building operation level rules.
The Multi-Protocol Gateway is a powerful and versatile service. In additional to threat protection and document processing capabilities, the Multi-Protocol Gateway can process requests between various protocols. The supported protocols are HTTP,HTTPS, WebSphere MQ, WebSphere JMS, IMS™, FTP, NFS, SFTP, and TIBCO EMS.
A single Multi-Protocol Gateway can have multiple front-side handlers that listen or poll for requests. The ability of configuring multiple front-side handlers allows a Multi-Protocol Gateway to receive requests from different protocols. For example, a
Multi-Protocol Gateway can have one front-side handler listening for HTTP requests and another handler polling a WebSphere MQ queue for messages. Both front-side handlers forward the incoming message to the Multi-Protocol Gateway for processing and forwarding to the remote server.
Unlike a Web Service Proxy service, a Multi-Protocol Gateway service cannot use a WSDL to determine a configuration.
- MPGW can accept all kinds of message formats like XML, SOAP,NON-XML,JSON
- It can accept all kinds of protocols as well
- We need to manually configure a match action and Processing policy
- We have a loopback mode in MPGW
- WSDL Definitions
- WSDL Types
- WSDL Message
- WSDP Port and Operation
- WSDL Binding
SLM has mainly 3 statements
- SSL Proxy Profile or Transport Layer Security
- When DataPower Acts as Server
Create SSL proxy profile by following the steps shown below , it can be referred in any Front side handler that supports SSL(Example HTTPS)
- When DataPower Acts as Client
- Upload certificate shared by server in cert/pubcert directory of Datapower File Management.
- Create SSL proxy profile as shown below.This can be either referred in proxy settings or set dynamically using routing-ssl-profile variable
- Server to which Datapower acts as client will share its certificate to Datapower (Client).
- Using certificate shared, a crypto certificate object is created.
- Crypto Validation credentials created using crypto certificate object will be included in crypto profile.
- Crypto profile created will be used in Datapower as SSL proxy profile
- TWO-WAY-SSL-Proxy-Profile :
A TWO-WAY-SSL-Proxy-Profile contains two crypto profiles one refers crypto validation credentials evaluated in response (Datapower as client to Backend) and other one refers crypto Identification credentials used in request flow(When Datapower acts as SSL server to front end systems)
- Message Level Security by Using AAA
AAA – Authentication Authorization and Auditing
AAA can be implemented in various ways like Digital Signature Method, LDAP Authentication and AAAInfo.xml file
AAA has mainly 5 steps:
- How to Extract the User’s identity from an incoming request
- How to Authenticate the User
- How to Extract the Resources
- How to Authorize the User
- Digital Signature Method
- Client/Consumer will be using their own Private Key to digitally sign a message and sends to Datapower.
- Client/Consumer will be sharing their public Certificate to Datapower, which we upload into Cert folder under File Management and Create a Crypto Certificate.
- The Created Crypto Certificate object will be used inside Crypto Validation Credentials
- LDAP Method
- Client/Consumer will be sending the username token and password as part of WS-Security Header.
- We extract the Header and Send it to LDAP Server for Authentication purpose
- xml Method
- Client/Consumer will be sending the username token and password as part of WS-Security Header
- We extract the Header and verify the same in the AAAinfo.xml file for Authentication purpose
An XML Manager provides the following capabilities
- Basic network configuration, such as load balancing and accessing remote servers.
- It acts as an XML parser in order to provide XML Threat Protection
- It helps in implementing Caching
- To configure the User Agent
We can use SOAPUI to test the Datapower Services
- We use probe to capture the ongoingtransactions with respect to a service.
- We can also set the log level to debug mode in Troubleshooting Panel.
- We can make use of Log targets and Log Categories especially in Prod, as we are not supposed to enable the probe in production.
- We have a default log file under logtemp directory in the file management, which will have all the logs with respect to a domain
- If we have to customize the log files, we create log targets
- We can save the logs in a file on the DP Appliance itself under logstore or logtemp directory
- We can also save the logs in an external server.
Every DP service will have a processing policy and every policy will have processing rules.
- Request rule to handle request messages
- Response rule to handle response messages
- Error Rule to handle error scenarios
In case of a dynamic backend, we update all the backend URL’s in an xml file and we use a generic XSLT which will read the URL from the xml file based on certain customized conditions and we set the routing variable var://service/routing-url in the XSLT.
Yes. I would rate myself as 6-7
The <xsl:param> element is used to declare a local or global parameter. The parameter is global if it’s declared as a top-level element, and local if it’s declared within a template.
<xsl:param name=”name” select=”expression”>
The <xsl:apply-templates> element applies a template to the current element or to the current element’s child nodes.
If we add a select attribute to the <xsl:apply-templates> element it will process only the child element that matches the value of the attribute. We can use the select attribute to specify the order in which the child nodes are processed.
The <xsl:call-template> element calls a named template.
- In terms of raw performance xsl:call-template is likely to be faster, as you are calling a specific named template, rather than telling the XSLT processor to pick the template which best matches
- With call-template you have to know what you’re calling. apply-templates is polymorphic – what gets called depends on what you find in the input, which means it is the key feature that enables XSLT to respond to variable or unpredictable input – essential when handling documents as distinct from structured data.
- apply-templates is usually (but not necessarily) used to process all or a subset of children of the current node with all applicable templates. This supports the recursiveness of XSLT application which is matching the (possible) recursiveness of the processed XML.
- call-template on the other hand is much more like a normal function call. You execute exactly one (named) template, usually with one or more parameters.
The <xsl:copy> element creates a copy of the current node.
Note: Namespace nodes of the current node are automatically copied as well, but child nodes and attributes of the current node are not automatically copied!
The <xsl:copy-of> element creates a copy of the current node.
Note: Namespace nodes, child nodes, and attributes of the current node are automatically copied as well!
Local – var://local/userdefinedname
A local context variable in the default (current) context.
The local context does not persist beyond the scope of the transaction. A transaction can include both a request component and a response component. The local context cannot be accessed by any object outside the scope of the transaction. In other words, a service cannot read and use the variable.
Context – var://context/contextdefinition/userdefinedname
Addresses a variable in a named context.
Service – mention any service variable for ex : var://service/routing-url, var://service/error-code, var://service/url-in
Addresses a variable that is made available to a DataPower service that is attached to a session.[
Passthrough is basically accepting and sending a request to the backend without modifying it in Datapower
We create an error rule in which we use a generic XSLT, which creates a fault message by reading the Service variables
<?xml version=”1.0″ encoding=”UTF-8″?>
<xsl:copy-of select=”dp:variable(‘var://service/error-message’)” />
Whenever we need to use DP EXTN Functions, we always need to declare the below namespace.
<dp:set-variable name=”variableName” value=”variableValue”/>
- dp:reject :
The appliance sends the denial message to the client in a SOAP fault message. Also stops document processing and optionally invokes the error rule for custom error handling
<dp:reject override=”true | false”>
- dp:set-http-request-header :
If a client request already includes the field identified by the name attribute, thisextension element overwrites the specified header field value in the client request.
If the header field does not exist, this extension function adds the specified name and value to the client request.
|Integrating and leveraging the WebSphere MQ messaging infrastructure.||Similar to Message Broker, DataPower can do any-to-any transformation (in theory, Yes. But in practice, you may need to use WebSphere Transformation Extender (WTX)).|
|Supports different protocols such as MQ, JMS, HTTP(S), Web Services, ftp, and convert one to the other.||Supports almost every security protocols and different authentication/authorization schemas, such as Web Service security/policy, TLS/SSL, SAML, LDAP, RADIUS, etc.|
|Supports a wide range of data formats, including XML, binary (COBOL, C), positional/delimited, and industry formats (EDI, SWIFT), and convert one to the other.||Provides field level security: WS-security down to the individual operation, encrypt & sign individual fields, nonrepudiation.|
|Provides a number of capabilities to customize mediation, including C/C++, ESQL, Java, XSLT, and PHP.||Data validation, parsing and filtering, and meta data manipulation.|
|WebSphere Adapters for enterprise applications (SAP, PeopleSoft and Siebel).||Transport level protocol conversions from any-to-any.|
|Offers z/OS clients platform-specific benefits (CICS, VSAM).|
We have a support team who takes care of Service deployments. We take an export of the service which needs to be deployed and keep it in a secured server by doing FTP. Our support team has some scripts, which they execute in the server and does the deployment
We can also use Export and Import configuration along with the Deployment Policy
An on-error action defines a named rule that enables user-defined error handling when subsequent processing encounters errors. This topic instructs how to define an on-error action.
The on-error action either stops processing or continues to the next processing step. Optionally, the action calls the named rule to handle the error condition. Without an on-error action, the default error handling is to stop processing and log a message.
A processing rule can contain one or more on-error actions. Each action defines error handling for subsequent actions until another on-error action is found. When another action is found, error-handling procedures are set to the new on-error action. As such, this action enables conditional error handling in a processing context.
Note: A processing policy can contain on-error actions and an error rule. When a processing policy contains both on-error actions and an error rule, the on-error action overrides the error rule. An error rule, if the processing policy contains one, is invoked when an error occurs during processing. In this case, the error rule acts as an error handler.
- Gathering the requirements from Client
- Preparing the Design Document
- Presenting the Design document to Client for approval
- Configuring the service in Development environment
- Testing and Troubleshooting of DP Services
- Migrating the services from Dev to test and to production environment
An application domain allows the administrators to partition an appliance into multiple logical configurations.For example the developers and production employees environment is different
- XML-Management Interface
- To securely back up the appliance configuration from the WebGUI:
- Click Administration => Main => System Control.
- Locate the Secure Backup section.
- From the Crypto certificate list, select the certificate to encrypt the secure backup.
- In the Destination field, enter the URL of the target directory for the backup files.
- Click Secure Backup to back up the appliance.