Designer 10.7 | Cloudstreams Development Help | CloudStreams Governance Project | Policies
 
Policies
 
Create a New Policy Wizard
General Properties View (Policy)
Action: Authorize User
Action: Identify Consumer
Action: Include Timestamps
Action: Log Invocation
Action: Monitor Service Performance
Action: Monitor Service Level Agreement (SLA)
Action: Require Encryption
Action: Require HTTP Basic Authentication
Action: Require SAML Token
Action: Require Signing
Action: Require SSL
Action: Require WSS Username
Action: Require X.509 Token
Action: Throttling Traffic Optimization
Action: Validate Schema
Use this editor to create policies for virtual services and connector virtual services.
A policy provides run-time governance capabilities to a virtual service or a connector virtual service. A policy is a sequence of actions that are carried out by CloudStreams when a consumer requests a particular service through CloudStreams. The actions in a policy perform activities such as identifying/authenticating consumers, validating digital signatures and capturing performance measurements.
You should create a policy for each virtual service. You can apply a single policy to one or more virtual services. A policy for virtual services can include the following kinds of actions:
*WS-SecurityPolicy 1.2 actions:
CloudStreams provides two kinds of actions that support WS-SecurityPolicy 1.2: authentication actions and XML security actions.
The authentication actions verify that the requests for virtual services contain a specified WS-SecurityPolicy element:
*Require SAML Token: Requires that a WSS Security Assertion Markup Language (SAML) assertion token be present in the SOAP message header to validate service consumers.
*Require WSS Username Token: Requires that a WSS username token and password be present in the SOAP message header to validate service consumers.
*Require X.509 Token: Requires that a WSS X.509 token be present in the SOAP message header to validate service consumers.
The XML security actions provide confidentiality (through encryption) and integrity (through signatures) for request and response messages. CloudStreams includes the following XML security actions:
*Require Signing: Requires that a request's XML element (which is represented by an XPath expression) be signed.
*Require Encryption: Requires that a request's XML element (which is represented by an XPath expression) be encrypted.
*Require SSL: Requires that requests be sent via SSL client certificates and can be used with both SOAP and REST services.
*Include Timestamps: Requires that timestamps be included in the request header. CloudStreams 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.
*Monitoring actions:
CloudStreams includes the following run-time monitoring actions:
*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 these performance conditions are violated.
*Monitor Service Level Agreement: This action 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 especially for particular consumer(s). You can 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.
*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 consumers in terms of resource usage, etc.
*Additional actions:
CloudStreams provides the following actions, which you can use in conjunction with the actions above.
*Identify Consumer: You use this action in conjunction with an authentication action (Require WSS Username Token, Require X.509 Token, or Require HTTP Basic Authentication). Alternatively, this action can be used alone to identify consumers only by host name or IP address.
*Require HTTP Basic Authentication, which uses HTTP basic authentication to verify the user name and passwords of consumers against the Integration Server's user account.
*Authorize User, which authorizes consumers against a list of users and/or a list of groups registered in the Integration Server. You use this action in conjunction with an authentication action (Require WSS Username Token, Require SAML Token, or Require HTTP Basic Authentication).
*Log Invocation, which logs request/response payloads. See Action: Log Invocation for General Data Protection Regulation (GDPR) related information.
*Validate Schema, which validates all XML request and/or response messages against an XML schema referenced in the WSDL.
Each default connector virtual service has a default policy, which you cannot modify. However, you can create additional connector virtual services with custom policies. If you create a connector virtual service with a custom policy, you can include only the monitoring, logging, and schema validation actions. (The virtual services, which receive the inbound requests, handle the security.) For example, you might want to create a custom policy that monitors run-time performance, customizes how the service invocations are logged, or optimizes server traffic.
When you create or modify a policy, you:
1. Specify the services to which the policy should apply. A policy can apply to one or more virtual services or to one or more connector virtual services, but not to both types of services.
2. Add the desired actions to the policy and configure their parameters.
3. Activate the policy when you are ready to put it into effect. When you deploy the virtual services or connector virtual services to which the policy is applied, the policy will also be deployed.