Actions that Run-Time Policies Can Execute
A run-time action is a single task that is included in a run-time policy and is evaluated by a policy-enforcement point (PEP). Actions in run-time policies perform tasks such as identifying/authenticating consumers and logging transaction activity. You specify actions when you define the policy. The PEP evaluates actions in the order in which they appear in the list of actions.
CentraSite provides run-time action templates. A run-time action template is a definition of an action that can be used in a run-time policy. Most action templates specify a set of parameters associated with a particular policy action. For example, when you configure the action that identifies consumers you specify an identifier (for example, an HTTP Authentication token) to identify the consumers who are trying to access the services. You can include multiple actions in a single policy.
Using the action templates, you can configure the following types of run-time actions:
WS-SecurityPolicy 1.2 actionsMediator provides two kinds of actions that support WS-SecurityPolicy 1.2: authentication actions and XML security actions.
You use the authentication actions to verify that the service consumer has the proper credentials to access a virtual service. You can authenticate consumers by their WSS X.509 certificates, WSS Username tokens or WSS SAML tokens.
You use the XML security actions to provide confidentiality (through encryption) and integrity (through signatures) for request and response messages.
Monitoring actions Mediator provides the following run-time monitoring actions:
The “Monitor Service Performance” action, which monitors a user-specified set of run-time performance conditions for a virtual service, and sends alerts to a specified destination when these conditions are violated.
The “Monitor Service Level Agreement” action, which provides the same functionality as “Monitor Service Performance”, but this action is different because it enables you to monitor a virtual service's run-time performance for particular consumers. You configure this action to define a
Service Level Agreement (SLA), which is set of conditions that defines the level of performance that a specified consumer should expect from a service.
The “Throttling Traffic Optimization” action (not available in
Mediator versions below 9.0), which limits the number of service invocations allowed 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 consumers in terms of resource usage, etc.
Additional actions Mediator provides the following actions, which you can use in conjunction with the actions above.
“Identify Consumer”, which you use in conjunction with an authentication action (“Require WSS Username Token”, “Require WSS X.509 Token” or “Require HTTP Basic Authentication”). Alternatively, you can use this action alone to identify consumers only by host name or IP address.
“Require HTTP Basic Authentication”, which uses HTTP basic authentication to verify the consumer's authentication credentials contained in the request's Authorization header against the
Integration Server.
“Authorize User”, which authorizes consumers against a list of users and/or a list of groups registered in the
Integration Server on which
Mediator is running. You use this action in conjunction with an authentication action (“Require WSS Username Token”, “Require WSS SAML Token” or
Require HTTP Basic Authentication).
“Authorize Against Registered Consumers”, which authorizes consumer applications against all Application assets that are registered in
CentraSite as consumers for the service.
“Log Invocation”, which logs request/response payloads to a destination you specify.
“Validate Schema”, which validates all XML request and/or response messages against an XML schema referenced in the WSDL.
