Administering Mediator : The Built-In Run-Time Actions : The Built-In Run-Time Actions for Virtualized APIs : Policy Enforcement Actions
Policy Enforcement Actions
Mediator provides the following categories of policy enforcement actions:
JMS Routing Actions
JMS Routing actions route the incoming message to an API over JMS. For example, to a JMS queue where an API can then retrieve the message asynchronously.
*JMS Routing Rule: Specifies a JMS queue to which the Mediator is to submit the request and the destination to which the native API is to return the response.
*Set Message Properties: Specifies JMS message properties to authenticate client requests before submitting to the native APIs.
*Set JMS Headers: Specifies JMS headers to authenticate client requests before submitting to the native APIs.
Logging and Monitoring Actions
Logging and Monitoring actions monitor and collect information about the number of messages that were processed successfully or failed, the average execution time of message processing, and the number of alerts associated with an API.
*Log Invocations: Logs request or response payloads to a destination you specify.
*Monitor Service Level Agreement: Specifies a Service Level Agreement (SLA), which is set of conditions that define the level of performance that a specified client must expect from an API.
*Monitor Service Performance: This action provides the same functionality as Monitor Service Level Agreement but this action is different because it enables you to monitor the API's run-time performance for all clients. This action monitors a user-specified set of run-time performance conditions for an API and sends alerts to a specified destination when these performance conditions are violated.
Routing Actions
Routing actions route the incoming message (for example, directly to the API, routed according to the routing rules, or routed to a pool of servers for the purpose of load balancing and failover handling) to the desired endpoint.
*Straight Through Routing: Routes the requests directly to a native endpoint that you specify.
*Context Based Routing: Routes requests to different endpoints based on specific values that appear in the request message.
*Content Based Routing: Routes requests to different endpoints based on specific criteria that you specify.
*Load Balancing and Failover Routing: Routes the requests across multiple endpoints.
*Dynamic Routing: Routes the request to the dynamic URL generated during runtime.
*Set Custom Headers: Specifies the HTTP headers for the outgoing message to the native service.
Security Actions
Security actions provide client validation (through WSS X.509 certificates, WSS username tokens, and so on), confidentiality (through encryption) and integrity (through signatures) for request and response messages.
For the client validation, Mediator maintains a list of consumer applications specified in CentraSite that are authorized to access the API published to Mediator. Mediator synchronizes this list of consumer applications through a manual process initiated from CentraSite.
There are two different lists of consumers in Mediator:
*List of Registered Consumers: Registered consumers are those users and consumer applications (represented as Application assets) who are available in Mediator and who are also registered as consumers for the API in CentraSite.
*List of Global Consumers: Global consumers are those users and consumer applications (represented as Application assets) who are available in Mediator.
Mediator provides Evaluate actions that you can include in a message flow to identify and validate clients, and then configure their parameters to suit your needs. You use these Evaluate actions to:
*Identify the clients who are trying to access the APIs (through IP address or hostname).
*Validate the client's credentials.
Following is the list of security actions:
*Evaluate Client Certificate for SSL Connectivity: Mediator validates the client's certificate that the client submits to the API in CentraSite. The client certificate that is used to identify the client is supplied by the client to the Mediator during the SSL handshake over the transport layer.
*Evaluate Hostname:
*Mediator tries to identify the client against either the Registered Consumers list (the list of registered consumers in Mediator) or the Global Consumers list (the list of available consumers in Mediator).
*Mediator tries to validate the client's hostname against the specified list of consumers in the Integration Server on which Mediator is running.
*Evaluate HTTP Basic Authentication:
*Mediator tries to identify the client against either the Registered Consumers list (the list of registered consumers in Mediator) or the Global Consumers list (the list of available consumers in Mediator).
*Mediator tries to validate the client's authentication credentials contained in the request's Authorization header against the specified list of consumers in the Integration Server on which Mediator is running.
*Evaluate IP Address:
*Mediator tries to identify the client against either the Registered Consumers list (the list of registered consumers in Mediator) or the Global Consumers list (the list of available consumers in Mediator).
*Mediator tries to validate the client's IP address against the specified list of consumers in the Integration Server on which Mediator is running.
*Evaluate WSS Username Token: Applicable only for SOAP APIs.
*Mediator tries to identify the client against either the Registered Consumers list (the list of registered consumers in Mediator) or the Global Consumers list (the list of available consumers in Mediator).
*Mediator tries to validate the client's WSS username token against the specified list of consumers in the Integration Server on which Mediator is running.
*Evaluate Kerberos: Evaluate Kerberos policy can be used in any of the following scenarios:
*When the native service does not support Kerberos authentication.
*When you want to centrally configure Kerberos authentication in Mediator for services where Mediator is configured to forward the request to a clustered group of native servers through load balancer.
Mediator tries to authenticate the client based on the Kerberos token and the authenticated client principal name is verified with the Registered Consumers list (the list of registered consumers in Mediator) or the Global Consumers list (the list of available consumers in Mediator).
Note:  
Before configuring Kerberos, see Configuring Kerberos in Integration Server chapter in webMethods Integration Server Administrator’s Guide to complete the prerequisites.
*Evaluate OAuth2 Token:
*Mediator tries to identify the client against either the Registered Consumers list (the list of registered consumers in Mediator) or the Global Consumers list (the list of available consumers in Mediator).
*Mediator tries to validate the client's OAuth access token against the specified list of consumers in the Integration Server on which Mediator is running.
*Evaluate WSS X.509 Certificate: Applicable only for SOAP APIs.
*Mediator tries to identify the client against either the Registered Consumers list (the list of registered consumers in Mediator) or the Global Consumers list (the list of available consumers in Mediator).
*Mediator tries to validate the client's WSS X.509 token against the specified list of consumers in the Integration Server on which Mediator is running.
*Evaluate XPath Expression:
*Mediator tries to identify the client against either the Registered Consumers list (the list of registered consumers in Mediator) or the Global Consumers list (the list of available consumers in Mediator).
*Mediator tries to validate the client's XPath expression against the specified list of consumers in the Integration Server on which Mediator is running.
*Require Encryption: Applicable only for SOAP APIs. Requires a request's XML element (which is represented by an XPath expression) or parts of soap request such as soap body or soap headers to be encrypted.
*Require Signing: Applicable only for SOAP APIs. Requires a request's XML element (which is represented by an XPath expression) or parts of soap request such as soap body or soap headers to be signed.
*Require SSL: Applicable only for SOAP APIs. Requires that requests be sent through SSL client certificates.
*Require Timestamps: Applicable only for SOAP APIs. 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.
*Require WSS SAML Token: Applicable only for SOAP APIs. Uses a WSS Security Assertion Markup Language (SAML) assertion token to validate API clients. The following subject confirmation methods are supported:
*Bearer
*Holder of Key (Symmetric)
*Holder of Key (Asymmetric)
*Validate SAML Audience URIs: This policy validates the Audience Restriction in the conditions section of the SAML assertion. The policy verifies whether any valid Audience URI within one valid condition element in the SAML assertion matches with any of the configured URIs. If two conditions are available, then one of the audience URIs in the first condition, and one of the audience URIs in the second condition must match with any of the configured URIs in this policy for the virtual service.
Note:  
The Audience URI match is case-sensitive.
This policy is used in the following scenarios:
*when the native service is enforced with the SAML policy and if the service provider wants to delegate Audience Restriction validation to Mediator.
*when SAML policy is enforced for the virtual service in Mediator.
For more information on Audience URI, refer to the conditions and audience restriction sections in the SAML specification, available at the following location: https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf.
Traffic Management Action
*Throttling Traffic Optimization: Limits the number of service invocations during a specified time interval and sends alerts to a specified destination when the performance conditions are violated. You can use this action to avoid overloading the back-end services and their infrastructure, to limit specific clients in terms of resource usage, and so on.
*Service Result Cache: Enables caching of the results of the SOAP and REST API invocations. You can use this action to improve the throughput of an API call.
Validation Action
*Validate Schema: Validates all XML request and response messages against an XML schema referenced in the WSDL.
Copyright © 2015- 2017 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback