This chapter explains the Oracle Communications Services Gatekeeper system administration security issues.
Some communication services use tunneled parameters to send information to Services Gatekeeper. You can use an interceptor to filter tunneled parameters to control this vulnerability and limit which xparameters can be set by inbound messages.
Filtering blocks requests that contain xparameters that are not specifically configured as allowed. This filtering applies to all of Services Gatekeeper, not just individual applications.
For general information about xparameters and filtering, see the discussion on using parameter tunneling in the Services Gatekeeper Extension Developer's Guide.
This section explains the behavior and configuration of the tunneled parameters filtering application.
When enabled, the interceptor_xparam application filters inbound messages for tunneled xparameters in inbound messages. Messages containing xparameters not explicitly allowed in the application's configuration file are rejected. Specifying a list of allowable xparameters enables tighter security in your Services Gatekeeper implementation. Filtering is on a global, not application, level.
The interceptor_xparam application is installed with Services Gatekeeper and is deployed as a standalone EAR file named xparam_interceptors.ear. It is implemented by the x-param-filter-interceptor interceptor.
To turn the application on, configure the customized interceptor chain and enable interceptor_xparam. You must configure the xparameters that you want to allow as described in "XParameter Filter Configuration File"; otherwise all requests that contain xparameters are rejected. If the application is active when Services Gatekeeper starts up, the application reads a configuration file that lists the allowed xparameters. If the list of allowed xparameters changes, you must update the configuration file and redeploy the filtering application. You can disable all tunneled parameters filtering by stopping or undeploying the EAR file and removing the interceptor from your interceptor chain.
The xparameter filter configuration file, xparam_filter_config.xml, is located in the xparam_interceptors.ear in the APP-INF/classes directory. The schema file, xparam_filter_config.xsd, is also available in this directory.
To allow an xparameter in a request, list its key as an <xParamKey> sub element within the <allowedXParams> element in xparam_filter_config.xml. For example:
<allowedXParams> <xParamKey>sms.protocol.id</xParamKey> <xParamK>sms.service.type<xParamKey> . . . </allowedXParams>
The xparameter keys are listed by communication service in the sections on tunneled parameters in the chapters in the Services Gatekeeper Communication Service Reference Guide. Some communication services do not support any xparameters.
If an xparameter is not configured in xparam_filter_config.xml, a SOAP request that passes the xparameter is rejected.
The following is an example of a rejection response to a request that passed the xparameter called dest_addr_subunit:
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<env:Fault>
<faultcode>env:Server</faultcode>
<faultstring/>
<detail>
<v2:ServiceException xmlns:v2="http://www.csapi.org/schema/parlayx/common/v2_1">
<messageId>SVC0001</messageId>
<text>A service error occurred. Error code is %1</text>
<variables>Error validating the request, xparam: dest_addr_subunit in the request data is not allowed.</variables>
</v2:ServiceException>
</detail>
</env:Fault>
</env:Body>
</env:Envelope>
See "Internal XParameters" for information about exceptions for xparameters that are not rejected.
It is possible for custom interceptors to insert xparameters on behalf of an application. To prevent these internal xparameters from being rejected by the filter, ensure that any custom interceptor that adds xparameters is executed after the x-param-filter-interceptor in the interceptor chain.
Xparameters added to a request through the <contextAttribute> of an SLA are not rejected because the InjectValuesInRequestContextFromSLA interceptor executes after x-param-filter-interceptor.
See "Using Service Interceptors to Manipulate Requests" in the Services Gatekeeper Extension Developer's Guide for information about the order of execution of custom interceptors.