CentraSite User's Guide : Runtime Governance : Run-Time Policy Management : Built-In Run-Time Actions Reference (CentraSite Control) : Built-in Actions for Run-Time Policies (CentraSite Control)
Built-in Actions for Run-Time Policies (CentraSite Control)
This section describes the built-in run-time actions that you can include in run-time policies for virtual services.
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 through 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 a list of groups registered in the Integration Server on which Mediator is running.
Input Parameters
Perform authorization against list of users
Boolean. Authorizes consumers against a list of users who are registered in the Integration Server on which Mediator is running. Specify one or more users in the fields below this option.
Perform authorization against list of groups
Boolean. Authorizes consumers against a list of groups who are registered in the Integration Server on which Mediator is running. Specify one or more groups in the fields below this option.
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, and so on.) you specify. Alternatively, this action provides an option to allow anonymous users to access the assets.
Input Parameters
Anonymous Usage Allowed
Boolean. Specifies whether to allow all users to access the asset, without restriction.
Value
Description
False
Default. Allows only the users specified in the Identify User Using parameter to access the assets.
True
Allow all users to access the asset. In this case, do not configure the Identify User Using parameter.
Identify User Using
String. Specifies the kind of consumer identifier that the action uses to identify consumer applications.
Value
Description
IP Address
Identifies one or more consumer applications based on their originating IP addresses.
Host Name
Identifies consumer applications based on a host name.
HTTP Authentication Token
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 use preemptive authentication, you should also include the action Require HTTP Basic Authentication in the policy.
If you select to omit Require HTTP Basic Authentication, 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.
Note:  
If you select the value HTTP Authentication Token, do not include the Authorize Against Registered Consumers action in the policy. This is an invalid combination.
WS-Security Authentication Token
Validate user names and passwords that are transmitted in the SOAP message header in the WSS Username Token. If you select this value, you should also include the action Require WSS Username Token in the policy.
Custom Identification
Validates consumer applications based on an XML element (represented by an XPath expression).
Consumer Certificate
Identifies consumer applications based on information in a WSS X.509 certificate. If you select this value, you should also include the action Require WSS X.509 Token or the action Require Signing in the policy.
Client Certificate for SSL Connectivity
Validates the client's certificate that the consumer application submits to the asset in CentraSite. The client certificate that is used to identify the consumer is supplied by the client to the Mediator during the SSL handshake over the transport layer. In order to identify consumers by transport-level certificates, the run-time communication between the client and the Mediator must be over HTTPS and the client must pass a valid certificate.
To use this option, the following prerequisites must be met:
*In Integration Server, create a keystore and truststore, as described in webMethods Integration Server Administrator’s Guide.
*In Integration Server, create an HTTPS port, as described in webMethods Integration Server Administrator’s Guide.
*Configure Mediator by setting the IS Keystore and IS Truststore parameters, as described in t Administering webMethods Mediator.
*Configure Mediator by setting the HTTPS Ports Configuration parameter, as described in Administering webMethods Mediator.
When deciding which type of identifier to use to identify a consumer application, consider the following points:
*Whatever identifier you select 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 or response payloads. You can specify the log destination and the logging frequency. This action also logs other information about the requests or 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
Log the Following Payloads
String. Optional. Specifies whether to log all request payloads, all response payloads, or both.
Value
Description
Request
Log all request payloads.
Response
Log all response payloads.
Log Generation Frequency
String. Specifies how frequently to log the payload.
Value
Description
Always
Log all requests and responses.
On Success
Log only the successful responses and requests.
On Failure
Log only the failed requests and responses.
Send Data To
String. Specifies where to log the payload.
Important:  
Ensure that Mediator is configured to log the payloads to the destination(s) you specify here. For details about alerts and transaction logging, see  Administering webMethods Mediator.
Value
Description
CentraSite
Logs the payloads in 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 Administering webMethods Mediator.
Local Log
Logs the payloads in the server log of the Integration Server on which Mediator is running.
Also select 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
Logs the payloads in 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 > SNMP). For the procedure, see Administering webMethods Mediator.
Email
Sends the payloads to an SMTP email server, which sends them to the email address(es) you specify here. Mediator sends the payloads as email attachments that are compressed using gzip data compression. To specify multiple addresses, use the plus 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 Administering webMethods Mediator.
Audit Log
Logs the payloads in the Integration Server audit logger. For more information about logging, see the webMethods Audit Logging Guide.
Note:  
If you expect a high volume of events in your system, it is recommended that you select the Audit Log destination for this action.
EDA/Database
Logs the payloads in an EDA endpoint or Database destination that you configured in Integration Server Administrator:
*An EDA endpoint (that is, a default endpoint configured in the universal messaging configuration).
*A Database (that is, a JDBC connection pool is defined in Integration Server and associated with the Mediator functional alias).
Prerequisite: You must configure the EDA/Database destination in Integration Server on the Solutions > Mediator > Administration > EDA/Database Configuration page. For details, see Administering webMethods Mediator.
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 select whether to send an alert only once during the interval, or every time the violation occurs during the interval. (Mediator sends another alert the next time a condition is violated during a subsequent 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 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 plus 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. Select an appropriate operator.
Value
String Array. Specify an appropriate value.
Alert parameters
Object. Specify the following parameters for the alerts that reports 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.
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 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 Administering webMethods Mediator.
Local Log
Sends the alerts to the server log of the Integration Server on which Mediator is running.
Also select 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 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 plus 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 Administering webMethods Mediator.
EDA/Database
Sends the alerts to an EDA endpoint/Database destination that you configured in Integration Server Administrator:
*An EDA endpoint (that is, a default endpoint configured in the universal messaging configuration).
*A Database (that is, a JDBC connection pool is defined in Integration Server and associated with the Mediator functional alias).
Prerequisite: You must configure the EDA/Database destination in Integration Server on the Solutions > Mediator > Administration > EDA/Database Configuration page. For details, see Administering webMethods Mediator.
Alert Message
String. Optional. Specify a text message to include in the alert.
Monitor Service Level Agreement
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 or 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 select whether to send an alert only once during the interval, or every time the violation occurs during the interval. (Mediator sends another alert the next time a condition is violated during a subsequent 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 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 plus button to add multiple rows. If multiple parameters are used, they are connected by the AND operator.
Name Operator
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.
String Array. Select 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 applies. To specify multiple Application assets, use the plus button to add multiple rows.
Alert parameters
Object. Specify the following parameters for the alerts that reports 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.
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.
Rule Expiration Date
String. Specifies the date on which this Service Monitoring Performance action expires, in format MM/DD/YYYY.
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 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 Administering webMethods Mediator.
Local Log
Sends the alerts to the server log of the Integration Server on which Mediator is running.
Also select 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 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 plus 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 Administering webMethods Mediator.
EDA/Database
Sends the alerts to an EDA endpoint/Database destination that you configured in Integration Server Administrator:
*An EDA endpoint (that is, a default endpoint configured in the universal messaging configuration).
*A Database (that is, a JDBC connection pool is defined in Integration Server and associated with the Mediator functional alias).
Prerequisite: You must configure the EDA/Database destination in Integration Server on the Solutions > Mediator > Administration > EDA/Database Configuration page. For details, see 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 webMethods Integration Server Administrator’s Guide.
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 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 appears 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 does 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.
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 uses 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 looks 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 uses.
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 (that is, 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 uses either the WS-Security username token or the HTTP Basic-Auth user name value. There must 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
Namespace
String. Optional. Namespace of the element required to be encrypted.
Note:  
Enter the namespace prefix in the following format: xmlns:<prefix-name> . For example: xmlns:soapenv.
The generated XPath element in the policy should look similar to this:
<sp:SignedElements
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-security
policy/200702">
<sp:XPath
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
//soapenv:Body</sp:XPath>
</sp:SignedElements>
Element Required to be Encrypted
String. An XPath expression that represents the XML element that is required to be encrypted.
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 username or 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 select 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 forwards 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 User 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.
Authenticate Credentials
Required. Authorizes consumers against the list of consumers available in the Integration Server on which Mediator is running.
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 webMethods Integration Server Administrator’s Guide.
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 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.
Note:  
Keep the following in mind:
*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.
*You can include this action multiple times in a policy.
Input Parameters
Namespace
String. Optional. Namespace of the element required to be signed.
Note:  
Enter the namespace prefix in the following format: xmlns:<prefix-name> . For example: xmlns:soapenv.
The generated XPath element in the policy should look similar to this:
<sp:SignedElements
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-security
policy/200702">
<sp:XPath
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
//soapenv:Body</sp:XPath>
</sp:SignedElements>
Element Required to be Signed
String. An XPath expression that represents the XML element that is required to be signed.
Require SSL
Requires that requests be sent through 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
Client Certificate Required
Boolean. Specifies whether client certificates are required for the purposes of:
*Verifying the signature of signed SOAP requests or decrypting encrypted SOAP requests.
*Signing SOAP responses or encrypting SOAP responses.
Value
Description
Yes
Require client certificates.
No
Default. Do not require client certificates.
Require Timestamps
Note:  
Dependency requirement: A policy that includes this action must also include any one of the following actions: 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 Administering webMethods Mediator.
Input Parameters
SAML Subject Confirmation
String. Select one of the following SAML subject confirmation methods:
Value
Description
Holder of Key
Default. Select this option if consumers use the SAML V1.1 or V2.0 Holder-of-Key Web Browser SSO Profile, which allows for transport of holder-of-key assertions. In this scenario, the consumer presents a holder-of-key SAML assertion acquired from its preferred identity provider to access a web-based resource at a service provider.
If you select Holder of Key, Mediator also implicitly selects the timestamp and signing assertions to the virtual service definition (VSD). Thus, you should not add the Require Timestamps and Require Signing policy actions to a virtual service if the Require WSS SAML Token action is already applied.
Bearer
Select this option if consumers use SAML V1.1 Bearer token authentication, in which a Bearer token mechanism relies upon bearer semantics as a means by which the consumer conveys to Mediator the sender's identity.
If you select Bearer, the timestamp and signing assertions are added to the virtual service definition (VSD).
Note:  
If consumers use SAML 2.0 Sender-Vouches tokens, configure your system as described in Administering webMethods Mediator.
SAML Version
String. Specifies the WSS SAML Token version to use: 1.1 or 2.0.
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.
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. 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
Note:  
Keep the following in mind:
*This action is not available in Mediator versions below 9.0.
*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 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 does 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 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 does 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 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 does 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 plus 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 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 Administering webMethods Mediator.
Local Log
Sends the alerts to the server log of the Integration Server on which Mediator is running.
Also select 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 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 plus 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 Administering webMethods Mediator.
EDA/Database
Sends the alerts to an EDA endpoint/Database destination that you configured in Integration Server Administrator:
*An EDA endpoint (that is, a default endpoint configured in the universal messaging configuration).
*A Database (that is, a JDBC connection pool is defined in Integration Server and associated with the Mediator functional alias).
Prerequisite: You must configure the EDA/Database destination in Integration Server on the Solutions > Mediator > Administration > EDA/Database Configuration page. For details, see 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 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
Validate SOAP Message(s)
Object. Validates request and response messages. You may select both Request and Response.
Value
Description
Request
Validate all requests.
Response
Validate all responses.
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 (that is, 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.
Copyright © 2015- 2017 Software AG, Darmstadt, Germany. (Innovation Release)

Product LogoContact Support   |   Community   |   Feedback