Data masking is a technique whereby sensitive data is obscured in
some way to render it safe and to protect the actual data while having a
functional substitute for occasions when the real data is not required.
This policy is used to mask sensitive data in the custom error messages being processed and
sent to the application. Fields can be masked or filtered in the error messages. You can
configure the masking criteria as required for the XPath, JPath, and Regex expressions.
This policy can also be applied at the API scope level.
Note: webMethods API Gateway does not mask the payload, if the payload is sent as
a stream.
The table lists the masking criteria properties that you can
configure to mask the data in the request messages received:
Property
|
Description
|
Consumer
Applications
|
Specifies the applications for which the
masking criterion has to be applied.
Start typing the application name, select the application
from the type-ahead search results displayed, and click
to add one or more
applications.
You can use the delete icon
to delete the added
applications from the list.
|
XPath. Specifies the masking criteria for
XPath expressions in the error messages.
|
Masking Criteria
|
Click
Add masking criteria and provide the
following information and click
Add:
- Query
expression. Specify the query expression that has to be masked or
filtered.
- Masking Type.
Specifies the type of masking required. You select either
Mask or
Filter. Selecting
Mask replaces the value with the
given value (the default value being ********). Selecting
Filter removes the field
completely.
- Mask Value.
Appears only if you have selected the
Masking Type as
Mask. Provide a mask value.
You can add multiple masking criteria.
As
Query expression and
Mask Value properties support
variable framework, you can use the available variables.
In case of query expression, if you provide variable
syntax, the XPath is applied on the payload using the value that is resolved
from the variable given.
For example, if you provide a query expression
as ${request.headers.myxpath} and the corresponding mask value
as
${request.headers.var1} , and if the
incoming request header
myxpath is configured with value
//ns:cardNumber, then the card
number derived from the payload is masked with the header value in
var1 .
For details about the variables available in
webMethods API Gateway,
see
Variables Available in API Gateway.
- Namespace.
Specifies the following Namespace information:
- Namespace
Prefix. The namespace prefix of the payload expression to be
validated.
- Namespace URI.
The namespace URI of the payload expression to be validated
Note: You can add multiple namespace prefix and URI by
clicking
 .
|
JSONPath. This is applicable only for
REST API. Specifies the masking criteria for JSONPath expressions in the error
messages.
|
Masking Criteria
|
Click
Add masking criteria and provide the
following information and click
Add:
- Query
expression. Specify the query expression that has to be masked or
filtered.
- Masking Type.
Specifies the type of masking required. You select either
Mask or
Filter. Selecting
Mask replaces the value with the
given value (the default value being ********). Selecting
Filter removes the field
completely.
- Mask Value.
Appears only if you have selected the
Masking Type as
Mask. Provide a mask value.
As
Query expression and
Mask Value properties support
variable framework, you can use the available variables.
In case of query expression, if you provide variable
syntax, the JSONPath is applied on the payload using the value that is resolved
from the variable given.
For example, if you provide a query expression
as ${request.headers.myjsonpath} and the corresponding mask
value as
${request.headers.var1} , and if the
incoming request header
myjsonpath is configured with value
$.cardNumber, then the card
number derived from the payload is masked with the header value in
var1 .
For details about the variables available in
webMethods API Gateway,
see
Variables Available in API Gateway.
|
Regex. Specifies the masking criteria for
regular expressions in the error messages.
|
Masking Criteria
|
Click
Add masking criteria and provide the
following information and click
Add:
- Query
expression. Specify the query expression that has to be masked or
filtered.
- Masking Type.
Specifies the type of masking required. You select either
Mask or
Filter. Selecting
Mask replaces the value with the
given value (the default value being ********). Selecting
Filter removes the field
completely.
- Mask Value.
Appears only if you have selected the
Masking Type as
Mask. Provide a mask value.
As
Query expression and
Mask Value properties support
variable framework, you can use the available variables.
In case of query expression, if you provide variable
syntax, the regex is applied on the payload using the value that is resolved
from the variable given.
For example, if you provide a query expression
as ${request.headers.myregex} and the corresponding mask value
as
${request.headers.var1} , then the
regex is applied using the value configured in the request header
myregex and the derived value is
masked with the header value in
var1 .
For details about the variables available in
webMethods API Gateway,
see
Variables Available in API Gateway.
|
Apply for transaction Logging
|
Select this option to apply masking criteria for transactional logs.
When you select this option the transactional log for the response is
masked on top of response sent to the client.
|
Apply for payload
|
Select this option to apply masking
criteria for payload.
When you select this option the payload in the response
sent to the client is masked.
Note: When you select this option it automatically masks the
data in the transactional log.
|