|
The configuration settings on the Message Interception Points
tab determine how the request and response messages for the service are
processed as they pass through the Enterprise Gateway. Several message interception
points are exposed to enable you to hook into different stages of the
Enterprise Gateway's request processing cycle.
At each of these interception points, it is possible to run policies that are
specific to that stage of the request processing cycle. For example, you can
configure a logging policy to run just before the request has been sent to the
Web Service and then again just after the response has been received.
Typically, the configuration settings on this screen are automatically
configured when importing a service into the Web Services Repository based
on information contained in the WSDL. In cases where the WSDL contains
WS-Policy assertions, a number of policies are automatically generated
and hooked up to perform the relevant security operations on the message.
For example, policies are created to insert SAML assertions, WS-Security
Username Tokens, WS-Addressing headers, and WS-Security Timestamps into the
message. Similarly, filters are created to sign and encrypt the outbound
message, if necessary, and to decrypt and validate the signature on
the response from the Web Service.
Order of Execution:
It is important to note the following in terms of the order of
execution of the message interception points:
-
The interception points are executed in the following order:
1. Request from Client
2. User-defined Request Hooks
3. Request to Service
4. Response from Service
5. User-defined Response Hooks
6. Response to Client
-
In steps 1, 3, 4, and 6, the execution order is as follows:
A) Before Operation-specific Policy
B) Operation-specific Policy Shortcuts
C) After Operation-specific Policy
-
The overall order of all the message interception points is given
in the sequence below.
1. Request from Client:
This is the first message interception point, which enables you to run a policy
against the request as it is received by the Enterprise Gateway. Typically,
this is where authentication and authorization events should occur.
1A) Before Operation-specific Policy:
This is usually where authentication policies should be configured because it is
the earliest point in the request cycle that you can hook into. To select a policy
to run at this point, click the browse button, and select the checkbox next to a
previously configured policy.
1B)Operation-specific Policy Shortcuts:
If you want to run policies that are specific to the different operations
exposed by the Web Service, click the Edit button at the
bottom of the table to set this up. For example, you may want to perform
different validation on requests for the different operations.
On the Policy Shortcut Editor dialog, enter the
Operation Namespace and Operation Name
in the fields provided. Enter a regular expression used to match the value
of the SOAPAction HTTP header in the SOAPAction Regular Expression
field. Finally, select the policy to run requests for this operation by clicking
the browse button next to the Policy Shortcut field. Select
the checkbox next to the policy that you want to run.
1C) After Operation-specific Policy:
This enables you to run a policy on the request after all
the operation-level policies have been executed on the request. Select the
appropriate policy as described earlier by clicking the browse button.
2. User-defined Request Hooks:
Users should primarily use this interception point to hook in their own
custom-built request processing policies.
User-defined Request Policy:
Browse to your custom-built request processing policy using the browse
button as before.
3. Request to Service:
This enables you to alter the message before it is routed to the Web Service.
For example, if the service requires the message to be signed and encrypted,
you can configure the necessary policies here.
3A) Before Operation-specific Policy:
This enables run policies on the message before the
operation-level policies are run. Select the policy to run as outlined
in the previous sections.
3B) Operation-specific Policy Shortcuts:
Operation-level policies on the request to the Web Service can be run
here. For example, if the input policy for a particular operation
requires the body to be signed and encrypted, a
Locate XML Nodes filter can be run here to mark the
required nodes.
3C) After Operation-specific Policy:
This is the last interception point available before the message is routed
on to the Web Service. For example, if certain operation-level policies have
been run to mark parts of the message to be signed and encrypted, the signing
and encrypting filters should be run here.
4. Response from Service:
This is executed on the response returned from the Web Service.
4A) Before Operation-specific Policy:
If the response from the Web Service is encrypted, this interception point
enables you to decrypt the message before any of the
operation-level policies are run on the decrypted message.
4B) Operation-specific Policy Shortcuts:
The policies configured at this point run on specific operation-level responses
(for example, getHelloResponse) from the Web Service.
4C) After Operation-specific Policy:
This should be used to run policies after the operation-level
policies have been run. For example, this is the appropriate point to place an XML
Signature Verification filter.
5. User-defined Response Hooks:
You should primarily use this interception point to hook in custom-built
response processing policies.
User-defined Response Policy:
Browse to your custom-built response processing policy using the browse
button as before.
6. Response to Client:
This enables you to process the response before it is returned to the client.
6A) Before Operation-specific Policy:
As before, this enables you to process the message with a policy before the
operation-level policies are run on the response.
6B) Operation-specific Policy Shortcuts:
The policies listed here are run on each operation response.
6C) After Operation-specific Policy:
This is the very last point at which you can run policies to process
the response message before it is returned to the client. For example,
if you are required to return a signed and encrypted response message to
the client, the signing and encrypting should be done at this point.
|