Version 9.6	SEARCH   CONTENTS   |   PDF BOOKS   |   HOME   UP   PREV   NEXT

This section describes the built-in run-time actions that you can include in run-time policies for virtual services. You use these actions only when you are using CentraSite Control to create run-time policies for virtual services. The content is organized under the following sections:

• Summary of the Run-Time Actions for Virtual Services

• The watt.server.auth.skipForMediator Property

• Action Evaluation Order and Dependencies

• Usage Cases for Identifying/Authenticating Consumers

• Run-Time Actions Reference for Virtual Services

Summary of the Run-Time Actions for Virtual Services

You can include the following kinds of built-in run-time actions in the run-time policies for virtual services:

• WS-SecurityPolicy 1.2 Actions

• Monitoring Actions

• Additional Actions

WS-SecurityPolicy 1.2 Actions

Mediator provides two kinds of actions that support WS-SecurityPolicy 1.2: authentication actions and XML security actions.

Authentication Actions (WS-SecurityPolicy 1.2)

Mediator uses the following authentication actions to verify that the requests for virtual services contain a specified WS-Security element:

XML Security Actions (WS-SecurityPolicy 1.2)

These actions provide confidentiality (through encryption) and integrity (through signatures) for request and response messages.

Monitoring Actions

Mediator provides the following run-time monitoring actions:

Additional Actions

Mediator provides the following actions, which you can use in conjunction with the actions above.

The watt.server.auth.skipForMediator Property

This property specifies whether Integration Server authenticates requests for Mediator. You must set this property to true.

No request to Mediator should be authenticated by Integration Server. Instead, authentication should be handled by Mediator. Thus, to enable Mediator to authenticate requests, you must set skipForMediator to true (by default it is false).

When this parameter is set to true, Integration Server skips authentication for Mediator requests and allows the user credentials (of any type) to pass through so that Mediator can authenticate them. If you change the setting of this parameter, you must restart Integration Server for the changes to take effect.

To set skipForMediator to true

1. In the Integration Server Administrator, click Settings > Extended.

2. Click Show and Hide Keys.

   Look for the watt.server.auth.skipForMediator property and ensure it is set to true.

3. If the watt.server.auth.skipForMediator property is not present, add it as follows:

   1. Click Edit Extended Settings.

   2. Type watt.server.auth.skipForMediator=true on a separate line.

   3. Click Save.

   4. Restart Integration Server.

Action Evaluation Order and Dependencies

When you deploy a virtual service, CentraSite automatically validates the service's run-time policy (or policies) to ensure that:

• Any action that appears in a single policy multiple times is allowed to appear multiple times.

  For those actions that can appear in a policy only once (for example, Identify Consumer), Mediator will choose only one, which might cause problems or unintended results.

• All action dependencies are properly met. That is, some actions must be used in conjunction with another particular action.

CentraSite will inform you of any violation, and you will need to correct the violations before deploying the service.

• Effective Policies

Effective Policies

When you deploy a virtual service to Mediator, CentraSite combines the actions specified within the service's run-time policy (or policies) that apply to the virtual service, and generates what is called the effective policy for the virtual service. For example, suppose your virtual service is within the scope of two run-time policies: one policy that performs a logging action and another policy that performs a security action. When you deploy the virtual service, CentraSite automatically combines the two policies into one effective policy. The effective policy, which contains both the logging action and the security action, is the policy that CentraSite actually deploys to Mediator with the virtual service.

When CentraSite generates the effective policy, it validates the resulting action list to ensure that it contains no conflicting or incompatible actions. If the list contains conflicts or inconsistencies, CentraSite resolves them according to Policy Resolution Rules. For example, an action list can include only one Identify Consumer action. If the resulting action list contains multiple Identify Consumer actions, CentraSite resolves the conflict by including only one of the actions (selected according to a set of internal rules) in the effective policy and omitting the others.

The effective policy that CentraSite produces for a virtual service is contained in an object called a virtual service definition (VSD). The VSD is given to Mediator when you deploy the virtual service. After you deploy a virtual service, you can view its VSD (and thus examine the effective policy that CentraSite generated for it) from the CentraSite user interface or from the Mediator user interface.

The following table shows:

• The order in which Mediator evaluates the actions.

• Action dependencies (that is, whether an action must be used in conjunction with another particular action).

• Whether an action can be included multiple times in a single policy. If an action cannot be included multiple times in a single policy, Mediator selects just one for the effective policy, which may cause problems or unintended results.

Usage Cases for Identifying/Authenticating Consumers

When deciding which type of identifier to use to identify a consumer application, consider the following points:

• Whatever identifier you choose to identify a consumer application, it must be unique to the application. Identifiers that represent user names are often not suitable because the identified users might submit requests for multiple applications.

• Identifying applications by IP address or host name is often a suitable choice, however, it does create a dependency on the network infrastructure. If a consumer application moves to a new machine, or its IP address changes, you must update the identifiers in the application asset.

• Using X.509 certificates or a custom token that is extracted from the SOAP message itself (using an XPATH expression), is often the most trouble-free way to identify a consumer application.

Following are some common combinations of actions used to authenticate/identify consumers.

• Scenario 1: Identify consumers by IP address or host name

  • The simplest way to identify consumers is to use the Identify Consumer action and set its Identify User Using parameter to specify either a host name or an IP address (or a range of IP addresses).

• Scenario 2: Authenticate consumers by HTTP authentication token
  Use the following actions:

  • Identify Consumer action, and set its Identify User Using parameter to HTTP Authentication Token (to identify consumers using the token derived from the HTTP header).

  • Require HTTP Basic Authentication.

  • Additionally, you can use one or both of the following:

    • Authorize User action (to authorize a list of users and/or groups registered in the Integration Server on which Mediator is running).

    • Authorize Against Registered Consumers action (to authorize consumer applications against all Application assets registered as consumers for a service in CentraSite).

• Scenario 3: Authenticate consumers by WS-Security authentication token
  Use the following actions:

  • Identify Consumer action, and set its Identify User Using parameter to WS-Security Authentication Token (to identify consumers using the token derived from the WSS Header).

  • Require WSS Username Token action.

  • Additionally, you can use one or both of the following:

    • Authorize User action (to authorize a list of users and/or groups registered in the Integration Server on which Mediator is running).

    • Authorize Against Registered Consumers action (to authorize consumer applications against all Application assets registered as consumers for a service in CentraSite).

• Scenario 4: Authenticate consumers by WSS X.509 token

  • Identify Consumer action, and set its Identify User Using parameter to Consumer Certificate (to identify consumers using the WSS X.509 token).

  • Require WSS X.509 Token action

  • Require SSL action.

Run-Time Actions Reference for Virtual Services

This section describes the following built-in run-time actions that you can include in run-time policies for virtual services:

• Authorize Against Registered Consumers

• Authorize User

• Identify Consumer

• Log Invocation

• Monitor Service Performance

• Monitor Service Level Agreement

• Require Encryption

• Require HTTP Basic Authentication

• Require Signing

• Require SSL

• Require Timestamps

• Require WSS SAML Token

• Require WSS Username Token

• Require WSS X.509 Token

• Throttling Traffic Optimization

• Validate Schema

Authorize Against Registered Consumers

Note:
Dependency requirement: A policy that includes this action must also include the Identify Consumer action. However, if the Identify Consumer action is set to identify users via the HTTP Authentication Token option, then "Authorize Against Registered Consumers" should not be included in the policy.

Authorizes consumer applications against all consumer applications who are registered in CentraSite as consumers for the service.

Input Parameters

None.

Authorize User

Note:
Dependency requirement: A policy that includes this action must also include one of the following: the Require WSS SAML Token action or the Identify Consumer action with one of the following options selected: "HTTP Authentication Token" or "WS-Security Authentication Token".

Authorizes consumers against a list of users and/or a list of groups registered in the Integration Server on which Mediator is running.

Input Parameters

Note:
By default, both of the input parameters are selected. If you de-select one of these parameters, the fields showing the list of users (or groups) is not displayed.

Identify Consumer

Mediator uses this action to identify consumer applications based on the kind of consumer identifier (IP address, HTTP authorization token, etc.) you specify. Alternatively, this action provides an option to allow anonymous users to access the assets.

Input Parameters

False

True

IP Address

Host Name

HTTP Authentication Token

WS-Security Authentication Token

Custom Identification

Consumer Certificate

Client Certificate for SSL Connectivity

When deciding which type of identifier to use to identify a consumer application, consider the following points:

• Whatever identifier you choose to identify a consumer application, it must be unique to the application. Identifiers that represent user names are often not suitable because the identified users might submit requests for multiple applications.

• Identifying applications by IP address or host name is often a suitable choice, however, it does create a dependency on the network infrastructure. If a consumer application moves to a new machine, or its IP address changes, you must update the identifiers in the application asset.

• Using X.509 certificates or a custom token that is extracted from the SOAP or XML message itself (using an XPATH expression), is often the most trouble-free way to identify a consumer application.

Log Invocation

Logs request/response payloads. You can specify the log destination and the logging frequency. This action also logs other information about the requests/responses, such as the service name, operation name, the Integration Server user, a timestamp, and the response time.

Note:
You can include this action multiple times in a policy.

Input Parameters

Request

Response

Always

On Success

On Failure

CentraSite

Local Log

SNMP

Email

Audit Log

Monitor Service Performance

This action monitors a user-specified set of run-time performance conditions for a virtual service, and sends alerts to a specified destination when the performance conditions are violated. You can include this action multiple times in a single policy.

For the counter-based metrics (Total Request Count, Success Count, Fault Count), Mediator sends an alert as soon as the performance condition is violated, without having to wait until the end of the metrics tracking interval. You can choose whether to send an alert only once during the interval, or every time the violation occurs during the interval. (Mediator will send another alert the next time a condition is violated during a subsequent interval.) For information about the metrics tracking interval, see The Metrics Tracking Interval.

For the aggregated metrics (Average Response Time, Minimum Response Time, Maximum Response Time), Mediator aggregates the response times at the end of the interval, and then sends an alert if the performance condition is violated.

This action does not include metrics for failed invocations.

Note:
To enable Mediator to publish performance metrics, you must configure Mediator to communicate with CentraSite (in the Integration Server Administrator, go to Solutions > Mediator > Administration > CentraSite Communication). For the procedure, see the section Configuring Communication with CentraSite in the document Administering webMethods Mediator.

Input Parameters

Action Configuration parameters	Specify one or more conditions to monitor. To do this, specify a metric, operator, and a value for each metric. To specify multiple conditions, use the button to add multiple rows. If multiple parameters are used, they are connected by the AND operator.
Name	String Array The metrics to monitor.
	Value	Description
	Availability	Indicates whether the service was available to the specified consumers in the current interval.
	Average Response Time	The average amount of time it took the service to complete all invocations in the current interval. Response time is measured from the moment Mediator receives the request until the moment it returns the response to the caller.
	Fault Count	The number of faults returned in the current interval.
	Maximum Response Time	The maximum amount of time to respond to a request in the current interval.
	Minimum Response Time	The minimum amount of time to respond to a request in the current interval.
	Successful Request Count	The number of successful requests in the current interval.
	Total Request Count	The total number of requests (successful and unsuccessful) in the current interval.
Operator	String Array Choose an appropriate operator.
Value	String Array Specify an appropriate value.
Alert parameters	Object Specify the following parameters for the alerts that will report on the conditions:
Alert Interval	Number The time period (in minutes) in which to monitor performance before sending an alert if a condition is violated. For information about the metrics tracking interval, see The Metrics Tracking Interval.
Alert Frequency	String Specifies how frequently to issue alerts for the counter-based metrics (Total Request Count, Success Count, Fault Count).
	Value	Description
	Every Time	Issue an alert every time one of the specified conditions is violated.
	Only Once	Issue an alert only the first time one of the specified conditions is violated.
Reply to Destination	String Specifies where to send the alerts. Important: Ensure that Mediator is configured to send event notifications to the destination(s) you specify here. For details, see Alerts and Transaction Logging in the document Administering webMethods Mediator.
	Value	Description
	CentraSite	Sends the alerts to the virtual service's Events profile in CentraSite. Prerequisite: You must configure Mediator to communicate with CentraSite (in the Integration Server Administrator, go to Solutions > Mediator > Administration > CentraSite Communication). For the procedure, see the section Configuring Communication with CentraSite in the document Administering webMethods Mediator.
	Local Log	Sends the alerts to the server log of the Integration Server on which Mediator is running. Also choose a value in the Log Level field: Info: Logs error-level, warning-level, and informational-level alerts. Warn: Logs error-level and warning-level alerts. Error: Logs only error-level alerts. Important: The Integration Server Administrator's logging level for Mediator should match the logging level specified for this action (go to Settings > Logging > Server Logger).
	SNMP	Sends the alerts to CentraSite's SNMP server or a third-party SNMP server. Prerequisite: You must configure the SNMP server destination (in the Integration Server Administrator, go to Solutions > Mediator > Administration > Email). For the procedure, see the section SNMP Destinations for Run-Time Events in the document Administering webMethods Mediator.
	Email	Sends the alerts to an SMTP email server, which sends them to the email address(es) you specify here. To specify multiple addresses, use the button to add rows. Prerequisite: You must configure the SMTP server destination (in the Integration Server Administrator, go to Solutions > Mediator > Administration > Email). For the procedure, see the section SMTP Destinations for Run-Time Events in the document Administering webMethods Mediator.
Alert Message	String Optional. Specify a text message to include in the alert.

Monitor Service Level Agreement

Note:
Dependency requirement: A policy that includes this action must also include the Identify Consumer action.

This action is similar to the Monitor Service Performance action. Both actions can monitor the same set of run-time performance conditions for a virtual service, and then send alerts when the performance conditions are violated. This action is different because it enables you to monitor run-time performance for one or more specified consumers. You can include this action multiple times in a single policy.

You can configure this action to define a Service Level Agreement (SLA), which is a set of conditions that defines the level of performance that a consumer should expect from a service. You can use this action to identify whether a service's threshold rules are met or exceeded. For example, you might define an agreement with a particular consumer that sends an alert to the consumer if responses are not sent within a certain maximum response time. You can configure SLAs for each virtual service/consumer application combination.

For the counter-based metrics (Total Request Count, Success Count, Fault Count), Mediator sends an alert as soon as the performance condition is violated, without having to wait until the end of the metrics tracking interval. You can choose whether to send an alert only once during the interval, or every time the violation occurs during the interval. (Mediator will send another alert the next time a condition is violated during a subsequent interval.) For information about the metrics tracking interval, see The Metrics Tracking Interval.

For the aggregated metrics (Average Response Time, Minimum Response Time, Maximum Response Time), Mediator aggregates the response times at the end of the interval, and then sends an alert if the performance condition is violated.

This action does not include metrics for failed invocations.

Note:
To enable Mediator to publish performance metrics, you must configure Mediator to communicate with CentraSite (in the Integration Server Administrator, go to Solutions > Mediator > Administration > CentraSite Communication). For the procedure, see the section Configuring Communication with CentraSite in the document Administering webMethods Mediator.

Input Parameters

Action Configuration parameters	Specify one or more conditions to monitor. To do this, specify a metric, operator, and value for each metric. To specify multiple conditions, use the button to add multiple rows. If multiple parameters are used, they are connected by the AND operator.
Name	String Array The metrics to monitor.
	Value	Description
	Availability	Indicates whether the service was available to the specified consumers in the current interval.
	Average Response Time	The average amount of time it took the service to complete all invocations in the current interval. Response time is measured from the moment Mediator receives the request until the moment it returns the response to the caller.
	Fault Count	Indicates the number of faults returned in the current interval.
	Maximum Response Time	The maximum amount of time to respond to a request in the current interval.
	Minimum Response Time	The minimum amount of time to respond to a request in the current interval.
	Successful Request Count	The number of successful requests in the current interval.
	Total Request Count	The total number of requests (successful and unsuccessful) in the current interval.
	Operator	String Array Choose an appropriate operator.
Value	String Array Specify an appropriate value.
Alert for Consumer Applications	Object Array Specify the Application asset(s) to which this Service Level Agreement will apply. To specify multiple Application assets, use the button to add multiple rows.
Alert parameters	Object Specify the following parameters for the alerts that will report on the Service Level Agreement conditions:
Alert Interval	Number The time period (in minutes) in which to monitor performance before sending an alert if a condition is violated. For information about the metrics tracking interval, see The Metrics Tracking Interval.
Alert Frequency	String Specifies how frequently to issue alerts for the counter-based metrics (Total Request Count, Success Count, Fault Count).
	Value	Description
	Every Time	Issue an alert every time one of the specified conditions is violated.
	Only Once	Issue an alert only the first time one of the specified conditions is violated.
Reply to Destination	String Specifies where to log the alert. Important: Ensure that Mediator is configured to send event notifications to the destination(s) you specify here. For details, see Alerts and Transaction Logging in the document Administering webMethods Mediator.
	Value	Description
	CentraSite	Sends the alerts to the virtual service's Events profile in CentraSite. Prerequisite: You must configure Mediator to communicate with CentraSite (in the Integration Server Administrator, go to Solutions > Mediator > Administration > CentraSite Communication). For the procedure, see the section Configuring Communication with CentraSite in the document Administering webMethods Mediator.
	Local Log	Sends the alerts to the server log of the Integration Server on which Mediator is running. Also choose a value in the Log Level field: Info: Logs error-level, warning-level, and informational-level alerts. Warn: Logs error-level and warning-level alerts. Error: Logs only error-level alerts. Important: The Integration Server Administrator's logging level for Mediator should match the logging level specified for this action (go to Settings > Logging > Server Logger).
	SNMP	Sends the alerts to CentraSite's SNMP server or a third-party SNMP server. Prerequisite: You must configure the SNMP server destination (in the Integration Server Administrator, go to Solutions > Mediator > Administration > Email). For the procedure, see the section SNMP Destinations for Run-Time Events in the document Administering webMethods Mediator.
	Email	Sends the alerts to an SMTP email server, which sends them to the email address(es) you specify here. To specify multiple addresses, use the button to add rows. Prerequisite: You must configure the SMTP server destination (in the Integration Server Administrator, go to Solutions > Mediator > Administration > Email). For the procedure, see the section SMTP Destinations for Run-Time Events in the document Administering webMethods Mediator.
Alert Message	String Optional. Specify a text message to include in the alert.

Require Encryption

Requires that a request's XML element (which is represented by an XPath expression) be encrypted. This action supports WS-SecurityPolicy 1.2 and cannot be used with REST services.

Prerequisites

1. Configure Integration Server: Set up keystores and truststores in Integration Server, as described in Securing Communications with the Server in the document Administering webMethods Integration Server.

2. Configure Mediator: In the Integration Server Administrator, navigate to Solutions > Mediator > Administration > General and complete the IS Keystore Name, IS Truststore Name and Alias (signing) fields, as described in Keystore Configuration in the document Administering WebMethods Mediator.

When this policy action is set for the virtual service, Mediator provides decryption of incoming requests and encryption of outgoing responses. Mediator can encrypt and decrypt only individual elements in the SOAP message body that are defined by the XPath expressions configured for the policy action. Mediator requires that requests contain the encrypted elements that match those in the XPath expression. You must encrypt the entire element, not just the data between the element tags. Mediator rejects requests if the element name is not encrypted.

Important:
Do not encrypt the entire SOAP body because a SOAP request without an element will appear to Mediator to be malformed.

Mediator attempts to encrypt the response elements that match the XPath expressions with those defined for the policy. If the response does not have any elements that match the XPath expression, Mediator will not encrypt the response before sending. If the XPath expression resolves a portion of the response message, but Mediator cannot locate a certificate to encrypt the response, then Mediator sends a SOAP fault exception to the consumer and a Policy Violation event notification to CentraSite.

How Mediator Encrypts Responses

The Require Encryption action encrypts the response back to the client by dynamically setting a public key alias at run time. Mediator determines the public key alias as follows:

1. If Mediator can access the X.509 certificate of the client (based on the incoming request signature), it will use "useReqSigCert" as the public key alias.

   OR

2. If the Identify Consumer action is present in the policy (and it successfully identifies a consumer application), then Mediator will look for a public key alias with that consumer name in the "IS Keystore Name" property. The "IS Keystore Name" property is specified in the Integration Server Administrator, under Solutions > Mediator > Administration > General. This property should be set to an Integration Server keystore that Mediator will use.

   For an Identify Consumer action that allows for anonymous usage, Mediator does not require a consumer name in order to send encrypted responses. In this case, Mediator can use one of the following to encrypt the response in the following order, depending on what is present in the security element:

   • A signing certificate.

   • Consumer name.

   • WSS username, SAML token or X.509 certificate.

   • HTTP authorized user.

   OR

3. If Mediator can determine the current IS user from the request (i.e., if an Integration Server WS-Stack determined that Subject is present), then the first principal in that subject is used.

   OR

4. If the above steps all fail, then Mediator will use either the WS-Security username token or the HTTP Basic-Auth user name value. There should be a public key entry with the same name as the identified username.

Note:
You can include this action multiple times in a single policy.

Input Parameters

<sp:SignedElements xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
              <sp:XPath xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">//soapenv:Body</sp:XPath>
            </sp:SignedElements>

Require HTTP Basic Authentication

This action uses HTTP Basic authentication to verify the consumer's authentication credentials contained in the request's Authorization header. Mediator authorizes the credentials against the list of consumers available in the Integration Server on which Mediator is running. This type of consumer authentication is referred to as "preemptive authentication". If you want to perform "preemptive authentication", a policy that includes this action must also include the Identify Consumer action.

If the user/password value in the Authorization header cannot be authenticated as a valid Integration Server user (or if the Authorization header is not present in the request), a 500 SOAP fault is returned, and the client is presented with a security challenge. If the client successfully responds to the challenge, the user is authenticated. This type of consumer authentication is referred to as "non-preemptive authentication". If the client does not successfully respond to the challenge, a 401 "WWW-Authenticate: Basic" response is returned and the invocation is not routed to the policy engine. As a result, no events are recorded for that invocation, and its key performance indicator (KPI) data are not included in the performance metrics.

If you choose to omit the "Require HTTP Basic Authentication" action (and regardless of whether an Authorization header is present in the request or not), then:

• Mediator forwards the request to the native service, without attempting to authenticate the request.

• The native service returns a 401 "WWW-Authenticate: Basic" response, which Mediator will forward to the client; the client is presented with a security challenge. If the client successfully responds to the challenge, the user is authenticated.

In the case where a consumer sends a request with transport credentials (HTTP Basic authentication) and message credentials (WSS Username or WSS X.509 token), the message credentials take precedence over the transport credentials when Integration Server determines which credentials it should use for the session. For more information, see Require WSS Username Token and Require WSS X.509 Token. In addition, you must ensure that the service consumer that connects to the virtual service has an Integration Server user account.

Note:
Do not include the "Require HTTP Basic Authentication" action in a virtual service's run-time policy if you selected the OAuth2 option in the virtual service's Routing Protocol step.

Input Parameters

Note:
This input parameter is not available in Mediator versions prior to 9.0.

Require Signing

This action requires that a request's XML element (which is represented by an XPath expression) be signed. This action supports WS-SecurityPolicy 1.2.

Prerequisites

1. Configure Integration Server: Set up keystores and truststores in Integration Server, as described in Securing Communications with the Server in the document Administering webMethods Integration Server.

2. Configure Mediator: In the Integration Server Administrator, navigate to Solutions > Mediator > Administration > General and complete the IS Keystore Name, IS Truststore Name and Alias (signing) fields, as described in Keystore Configuration in the document Administering WebMethods Mediator. Mediator uses the signing alias specified in the Alias (signing) field to sign the response.

When this action is set for the virtual service, Mediator validates that the requests are properly signed, and provides signing for responses. Mediator provides support both for signing an entire SOAP message body or individual elements of the SOAP message body.

Mediator uses a digital signature element in the security header to verify that all elements matching the XPath expression were signed. If the request contains elements that were not signed or no signature is present, then Mediator rejects the request.

Notes:

1. You must map the public certificate of the key used to sign the request to an Integration Server user. If the certificate is not mapped, Mediator returns a SOAP fault to the caller.
2. You can include this action multiple times in a policy.

Input Parameters

<sp:SignedElements xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
              <sp:XPath xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">//soapenv:Body</sp:XPath>
            </sp:SignedElements>

Require SSL

Requires that requests be sent via SSL client certificates. This action supports WS-SecurityPolicy 1.2 and can be used for both SOAP and REST services.

When this action is set for the virtual service, Mediator ensures that requests are sent to the server using the HTTPS protocol (SSL). The action also specifies whether the client certificate is required. This allows Mediator to verify the client sending the request. If the policy requires the client certificate, but it is not presented, Mediator rejects the message.

When a client certificate is required, the Integration Server HTTPS port should be configured to request or require a client certificate.

Input Parameters

Yes

No

Require Timestamps

Note:
Dependency requirement: A policy that includes this action must also include all of the following actions: Require SSL, Require Signing, Require Encryption.

When this policy action is set for the virtual service, Mediator requires that timestamps be included in the request header. Mediator checks the timestamp value against the current time to ensure that the request is not an old message. This serves to protect your system against attempts at message tampering, such as replay attacks. This action supports WS-SecurityPolicy 1.2 and cannot be used with REST services.

Mediator rejects the request if either of the following happens:

• Mediator receives a timestamp that exceeds the time defined by the timestamp element.

• A timestamp element is not included in the request.

Input Parameters

None.

Require WSS SAML Token

When this action is set for a virtual service, Mediator uses a WSS Security Assertion Markup Language (SAML) assertion token to validate service consumers. This action supports WS-SecurityPolicy 1.2 and cannot be used with REST services.

For more information about configuring your system for SAML token processing, see SAML Support in Mediator in the document Administering webMethods Mediator.

Input Parameters

Holder of Key

Bearer

Require WSS Username Token

Note:
Dependency requirement: A policy that includes this action must also include the Identify Consumer action.

When this policy action is set for the virtual service, Mediator uses WS-SecurityPolicy authentication to validate user names and passwords that are transmitted in the SOAP message header for the WSS Username token. This action supports WS-SecurityPolicy 1.2 and cannot be used with REST services.

In the case where a consumer is sending a request with both transport credentials (HTTP basic authentication) and message credentials (WSS Username or X.509 token), the message credentials take precedent over the transport credentials when Integration Server is determining which credentials it should use for the session. For more information, see Require HTTP Basic Authentication.

Mediator rejects requests that do not include the username token and password of an Integration Server user. Mediator only supports clear text passwords with this kind of authentication

Input Parameters

None.

Require WSS X.509 Token

Note:
Dependency requirement: A policy that includes this action must also include the Identify Consumer action.

Identifies consumers based on a WSS X.509 token. This action supports WS-SecurityPolicy 1.2 and cannot be used with REST services.

In the case where a consumer is sending a request with both transport credentials (HTTP Basic authentication) and message credentials (WSS X.509 token or WSS Username), the message credentials take precedence over the transport credentials when Integration Server is determining which credentials it should use for the session. For more information, see Require HTTP Basic Authentication. In addition, you must ensure that the service consumer that connects to the virtual service has an Integration Server user account.

Input Parameters

None.

Throttling Traffic Optimization

Notes:

1. This action is not available in Mediator versions below 9.0.
2. Dependency requirement: A policy that includes this action must also include the Identify Consumer action if the Limit Traffic for Applications option is selected.

This action limits the number of service invocations during a specified time interval, and sends alerts to a specified destination when the performance conditions are violated.

Reasons for limiting the service invocation traffic include:

• To avoid overloading the back-end services and their infrastructure.

• To limit specific consumers in terms of resource usage (that is, you can use the "Monitor Service Level Agreement" action to monitor performance conditions for a particular consumer, together with "Throttling Traffic Optimization" to limit the resource usage).

• To shield vulnerable servers, services, and even specific operations.

• For service consumption metering (billable pay-per-use services).

Note:
To enable Mediator to publish performance metrics, you must configure Mediator to communicate with CentraSite (in the Integration Server Administrator, go to Solutions > Mediator > Administration > CentraSite Communication). For the procedure, see the section Configuring Communication with CentraSite in the document Administering webMethods Mediator.

Input Parameters

Soft Limit	Number Optional. Specifies the maximum number of invocations allowed per Interval before issuing an alert. Reaching the soft limit will not affect further processing of requests (until the Hard Limit is reached). Note: The limit is reached when the total number of invocations coming from all all the consumer applications (specified in the Limit Traffic for Applications field) reaches the limit. Soft Limit is computed in an asynchronous manner; thus when multiple requests are made at the same time, it may be possible that the Soft Limit alert will not be strictly accurate.
Hard Limit	Number Required. Specifies the maximum number of invocations allowed per alert interval before stopping the processing of further requests and issuing an alert. Typically, this number should be higher than the soft limit. Note: The limit is reached when the total number of invocations coming from all all the consumer applications (specified in the Limit Traffic for Applications field) reaches the limit. Hard Limit is computed in an asynchronous manner; thus when multiple requests are made at the same time, it may be possible that the Hard Limit alert will not be strictly accurate.
Limit Traffic for Applications	String Specifies the consumer application(s) that this action applies to. To specify multiple consumer applications, use the button to add rows, or select Any Consumer to apply this action to any consumer application.
Interval	Number Specifies the amount of time for the soft limit and hard limit to be reached.
Frequency	String Specifies how frequently to issue alerts.
	Value	Description
	Every Time	Issue an alert every time the specified condition is violated.
	Only Once	Issue an alert only the first time the specified condition is violated.
Reply To Destination	String Optional. Specifies where to log the alerts. Important: Ensure that Mediator is configured to send event notifications to the destination(s) you specify here. For details, see Alerts and Transaction Logging in the document Administering webMethods Mediator.
	Value	Description
	CentraSite	Sends the alerts to the virtual service's Events profile in CentraSite. Prerequisite: You must configure Mediator to communicate with CentraSite (in the Integration Server Administrator, go to Solutions > Mediator > Administration > CentraSite Communication). For the procedure, see the section Configuring Communication with CentraSite in the document Administering webMethods Mediator.
	Local Log	Sends the alerts to the server log of the Integration Server on which Mediator is running. Also choose a value in the Log Level field: Info: Logs error-level, warning-level, and informational-level alerts. Warn: Logs error-level and warning-level alerts. Error: Logs only error-level alerts. Important: The Integration Server Administrator's logging level for Mediator should match the logging level specified for this action (go to Settings > Logging > Server Logger).
	SNMP	Sends the alerts to CentraSite's SNMP server or a third-party SNMP server. Prerequisite: You must configure the SNMP server destination (in the Integration Server Administrator, go to Solutions > Mediator > Administration > Email). For the procedure, see the section SNMP Destinations for Run-Time Events in the document Administering webMethods Mediator.
	Email	Sends the alerts to an SMTP email server, which sends them to the email address(es) you specify here. To specify multiple addresses, use the button to add rows. Prerequisite: You must configure the SMTP server destination (in the Integration Server Administrator, go to Solutions > Mediator > Administration > Email). For the procedure, see the section SMTP Destinations for Run-Time Events in the document Administering webMethods Mediator.
Alert Message for Soft Limit	String Optional. Specify a text message to include in the soft limit alert.
Alert Message for Hard Limit	String Optional. Specify a text message to include in the hard limit alert.

Validate Schema

This action validates all XML request and/or response messages against an XML schema referenced in the WSDL.

Mediator can enforce this policy action for messages sent between services. When this policy is set for the virtual service, Mediator validates XML request messages, response messages, or both, against the XML schema referenced in the WSDL.

Input Parameters

Request

Response

Important:
Be aware that Mediator does not remove wsu:Id attributes that may have been added to a request by a consumer as a result of security operations against request elements (i.e., signatures and encryptions). In this case, to avoid schema validation failures you would have to add a Request Handling step to the virtual service so that the requests are passed to an XSL transformation file that removes the wsu:Id attribute. For details about the Request Handling step, see the section Virtual Services in CentraSite Control .

www.softwareag.com

Copyright © 2005-2014 Software AG, Darmstadt, Germany.

SEARCH   CONTENTS   |   PDF BOOKS   |   HOME   UP   PREV   NEXT