CentraSite User's Guide : CentraSite and API Gateway Integration : Runtime Policy Mapping Details
Runtime Policy Mapping Details
This section describes how the runtime policies and their property values defined and published from CentraSite are mapped into API Gateway.
A runtime policy is published from CentraSite to API Gateway when a Virtual Service associated with the policy is published from CentraSite to API Gateway.
Publishing of runtime policies from CentraSite to API Gateway is performed by invoking the API Gateway Deployer Service.
Evaluate Kerberos
You can secure Web Service APIs using client's Kerberos token credentials. This policy action:
*Identifies the application against either the Registered Applications list or the Global Applications list in API Gateway.
*Validates the client's kerberos token against the list of users in the Integration Server on which API Gateway is running.
You can select the level at which the Kerberos identification and authentication should be enforced for APIs:
*Message level
*Transport layer
The Evaluate Kerberos policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the following policies under the Identify & Access stage in API Gateway:
*If this policy action is set to secure SOAP API at the message level at the message level using the parameter Enforcement Point: Message Level in CentraSite, then the policy Inbound Authentication - Message with the parameter Kerberos Token Authentication is included to the API's policy list in API Gateway.
*If this policy action is set to secure SOAP or REST API at the transport layer using the parameter Enforcement Point: Transport Level in CentraSite, then the policy Inbound Authentication - Transport with the parameter Kerberos Token Authentication is included to the API's policy list in API Gateway.
*If this policy action is set to identify the application (against a list of global or registered consumers) using the parameter Identify Consumer: Global Consumers/ Registered Consumers, then the policy Identify & Authorize Application is included to the API's policy list in API Gateway.
*If this policy action is set to NOT identify the application (against a list of global or registered consumers) using the parameter Identify Consumer: Do Not Identify, then the policy Identify & Authorize Application is NOT included to the API's policy list in API Gateway.
Enforcement Point: Message Level Security
The following table summarizes the mapping of the policy enforcement at the message level:
CentraSite
API Gateway
Notes
Service Principal Name Form:
*User
Service Principal Name Form:
*Username
Beginning with version 10.1, the parameter Service Principal Name Form is removed from CentraSite and API Gateway. This is because the service principal name form set to Host or Hostbased is no longer supported in Integration Server. Therefore, whenever the Evaluate Kerberos policy is defined for an API in CentraSite or API Gateway, the service principal name form defaults to User or Username.
Service Principal Name Form:
*Host
Service Principal Name Form:
*Hostbased
Service Principal Name
Service Principal Name
Service Principal Password
Service Principal Password
Identify Consumer:
*Do Not Identify
Not applicable
When the parameter Identify Consumer is set to Do Not Identify in CentraSite, the policy Identify and Authorize Application that is used to identify an application is NOT included to the API's list of policies in API Gateway.
Identify Consumer:
*Global Consumers
Application Lookup Condition:
*Global applications
When the parameter Identify Consumer is set to Global Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a global consumer application is included to the API's list of policies in API Gateway. Also, the parameter Identification Type is set to Kerberos Token in the policy Identify and Authorize Application.
Identify Consumer:
*Registered Consumers
Application Lookup Condition:
*Registered applications
When the parameter Identify Consumer is set to Registered Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a registered consumer application is included to the API's list of policies in API Gateway. Also, the parameter Identification Type is set to Kerberos Token in the policy Identify and Authorize Application.
Enforcement Point: Transport Layer Security
The following table summarizes the mapping of the policy enforcement at the transport layer:
CentraSite
API Gateway
Notes
Service Principal Name Form:
*User
Service Principal Name Form:
*Username
Beginning with version 10.1, the parameter Service Principal Name Form is removed from CentraSite and API Gateway. This is because the service principal name form set to Host or Hostbased is no longer supported in Integration Server. Therefore, whenever the Evaluate Kerberos policy is defined for an API in CentraSite or API Gateway, the service principal name form defaults to User or Username.
Service Principal Name Form:
*Host
Service Principal Name Form:
*Hostbased
Service Principal Name
Service Principal Name
Service Principal Password
Service Principal Password
Identify Consumer:
*Do Not Identify
Not applicable
When the parameter Identify Consumer is set to Do Not Identify in CentraSite, the policy Identify and Authorize Application that is used to identify an application is NOT included to the API's list of policies in API Gateway.
Identify Consumer:
*Global Consumers
Application Lookup Condition:
*Global applications
When the parameter Identify Consumer is set to Global Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a global consumer application is included to the API's list of policies in API Gateway. Also, the parameter Identification Type is set to Kerberos Token in the policy Identify and Authorize Application.
Identify Consumer:
*Registered Consumers
Application Lookup Condition:
*Registered applications
When the parameter Identify Consumer is set to Registered Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a registered consumer application is included to the API's list of policies in API Gateway. Also, the parameter Identification Type is set to Kerberos Token in the policy Identify and Authorize Application.
Evaluate HTTP Basic Authentication
You can secure Web Service APIs using HTTP basic authentication. This policy action:
*Identifies the application against either the Registered Applications list or the Global Applications list in API Gateway.
*Validates the client's credentials contained in the request's Authorization header against the list of users in the Integration Server on which API Gateway is running.
The Evaluate HTTP Basic Authentication policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the following policies under the Identify & Access stage in API Gateway:
*If this policy action is set to identify the application (against a list of global or registered Applications) using the parameter Identify Consumer: Global Consumers/ Registered Consumers, then the policy Identify & Authorize Application is included to the API's policy list in API Gateway.
*If this policy action is set to NOT identify the application (against a list of global or registered Applications) using the parameter Identify Consumer: Do Not Identify, then the policy Identify & Authorize Application is NOT included to the API's policy list in API Gateway.
*If this policy action is set to validate the client's credentials in the request's Authorization header against the list of users in Integration Server using the parameter Authenticate User set to true in CentraSite, then the policy Inbound Authentication - Transport is included to the API's policy list in API Gateway.
*If this policy action is set to NOT validate the client's credentials in the request's Authorization header against the list of users in Integration Server using the parameter Authenticate User set to false in CentraSite, then the policy Inbound Authentication - Transport is NOT included to the API's policy list in API Gateway.
*If this policy action is set to NOT validate the client's credentials in the request's Authorization header (using the parameter Authenticate User set to false) and NOT identify the application (using the parameter Identify Consumer set to Do Not Identify), then the policy Validate HTTP Headers is included to the API's policy list in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Identify Consumer:
*Do Not Identify
Not applicable
When the parameter Identify Consumer is set to Do Not Identify in CentraSite, the policy Identify and Authorize Application that is used to identify an application is NOT included to the API's list of policies in API Gateway.
Identify Consumer:
*Global Consumers
Application Lookup Condition:
*Global applications
When the parameter Identify Consumer is set to Global Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a global consumer application is included to the API's list of policies in API Gateway. Also, the parameter Identification Type is set to Kerberos Token in the policy Identify and Authorize Application.
Identify Consumer:
*Registered Consumers
Application Lookup Condition:
*Registered applications
When the parameter Identify Consumer is set to Registered Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a registered consumer application is included to the API's list of policies in API Gateway. Also, the parameter Identification Type is set to Kerberos Token in the policy Identify and Authorize Application.
Authenticate User (check box)
Not applicable
*When the parameter Authenticate User check box is selected (set to true) in CentraSite, the policy Inbound Authentication - Transport with the parameter HTTP Basic Authentication that is used to secure the API at the transport layer is included to the API's list of policies in API Gateway.
*When the parameter Authenticate User check box is NOT selected (set to false) in CentraSite, the policy Inbound Authentication - Transport that is used to secure the API at the transport layer is NOT included to the API's list of policies in API Gateway. Also, if the parameter Identify Consumer is set to Do Not Identify in CentraSite, the policy Validate HTTP Headers that is used to validate the presence of HTTP headers, or header values, or both in incoming API requests is included to the API's list of policies in API Gateway.
Evaluate Client Certificate for SSL Connectivity
You can secure Web Service APIs using client's SSL certificate. This policy action identifies the application against either the Registered Applications list or the Global Applications list in API Gateway.
The Evaluate Client Certificate for SSL Connectivity policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the policy Identify and Authorize Application under the Identify & Access stage in API Gateway
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Identify Consumer:
*Global Consumers
Application Lookup Condition:
*Global applications
When the parameter Identify Consumer is set to Global Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a global consumer application is included to the API's list of policies in API Gateway. Also, the parameter Identification Type is set to SSL Certificate in the policy Identify and Authorize Application.
Identify Consumer:
*Registered Consumers
Application Lookup Condition:
*Registered applications
When the parameter Identify Consumer is set to Registered Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a registered consumer application is included to the API's list of policies in API Gateway. Also, the parameter Identification Type is set to SSL Certificate in the policy Identify and Authorize Application.
Evaluate Hostname
You can secure Web Service APIs using client's host name. This policy action identifies the application against either the Registered Applications list or the Global Applications list in API Gateway.
The Evaluate Hostname policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the policy Identify and Authorize Application under the Identify & Access stage in API Gateway
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Identify Consumer:
*Global Consumers
Application Lookup Condition:
*Global applications
When the parameter Identify Consumer is set to Global Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a global consumer application is included to the API's list of policies in API Gateway. Also, the parameter Identification Type is set to Hostname Address in the policy Identify and Authorize Application.
Identify Consumer:
*Registered Consumers
Application Lookup Condition:
*Registered applications
When the parameter Identify Consumer is set to Registered Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a registered consumer application is included to the API's list of policies in API Gateway. Also, the parameter Identification Type is set to Hostname Address in the policy Identify and Authorize Application.
Evaluate IP Address
You can secure Web Service APIs using client's IP address. This policy action identifies the application against either the Registered Applications list or the Global Applications list in API Gateway.
The Evaluate Hostname policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the policy Identify and Authorize Application under the Identify & Access stage in API Gateway
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Identify Consumer:
*Global Consumers
Application Lookup Condition:
*Global applications
When the parameter Identify Consumer is set to Global Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a global consumer application is included to the API's list of policies in API Gateway. Also, the parameter Identification Type is set to IP Address Range in the policy Identify and Authorize Application.
Identify Consumer:
*Registered Consumers
Application Lookup Condition:
*Registered applications
When the parameter Identify Consumer is set to Registered Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a registered consumer application is included to the API's list of policies in API Gateway. Also, the parameter Identification Type is set to IP Address Range in the policy Identify and Authorize Application.
Evaluate XPath Expression
You can secure Web Service APIs using client's authentication credentials that are represented as an XPath expression. This policy action identifies the application against either the Registered Applications list or the Global Applications list in API Gateway.
The Evaluate XPath Expression policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the policy Identify & Authorize Application under the Identify & Access stage in API Gateway as follows:
*If this policy action is set to identify the application (against a list of global or registered Applications) using the parameter Identify Consumer: Global Consumers/ Registered Consumers, then the policy Identify & Authorize Application is included to the API's policy list in API Gateway.
*But, if this policy action is set to NOT identify the application (against a list of global or registered Applications) using the parameter Identify Consumer: Do Not Identify, it is not possible to publish the API from CentraSite to API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Identify Consumer:
*Do Not Identify
Not applicable
When the parameter Identify Consumer is set to Do Not Identify in CentraSite, publishing of API form CentraSite to API Gateway fails with the following exception: Could not deploy the asset <asset_name> on given target <API Gateway_name>.
To work around this issue, you have to set the value of the parameter Identify Consumer to either Global Consumers or Registered Consumers, and then publish the API to API Gateway.
Identify Consumer:
*Global Consumers
Application Lookup Condition:
*Global applications
When the parameter Identify Consumer is set to Global Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a global consumer application is included to the API's list of policies in API Gateway. Also, the parameter Identification Type is set to XPath expression in the policy Identify and Authorize Application.
Identify Consumer:
*Registered Consumers
Application Lookup Condition:
*Registered applications
When the parameter Identify Consumer is set to Registered Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a registered consumer application is included to the API's list of policies in API Gateway. Also, the parameter Identification Type is set to XPath expression in the policy Identify and Authorize Application.
Namespace:
*Prefix
Namespace:
*Namespace Prefix
Namespace:
*URI
Namespace:
*Namespace URI
XPath Expression
Identification Query:
*Query Expression
Evaluate OAuth2 Token
You can secure Web Service APIs using client's OAuth2 token credentials. This policy action identifies the application against either the Registered Applications list or the Global Applications list in API Gateway.
The Evaluate OAuth2 Token policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the policy Identify & Authorize Application under the Identify & Access stage in API Gateway as follows:
*If this policy action is set to identify the application (against a list of global or registered Applications) using the parameter Identify Consumer: Global Applications / Registered Applications, then the policy Identify & Authorize Application is included to the API's policy list in API Gateway.
*If this policy action is set to NOT identify the application (against a list of global or registered Applications) using the parameter Identify Consumer: Do Not Identify, then the policy Identify & Authorize Application is NOT included to the API's policy list in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Identify Consumer:
*Do Not Identify
Not applicable
When the parameter Identify Consumer is set to any of the three options in CentraSite, the policy Identify and Authorize Application that is used to identify an application is included to the API's list of policies in API Gateway. The parameter Identification Type is set to OAuth2 Token in the policy Identify and Authorize Application. Also, the policy is internally defined to identify the application against the Registered Applications list in API Gateway.
Identify Consumer:
*Global Consumers
Identify Consumer:
*Registered Consumers
Authenticate Access Token:
*True
*False
Not applicable
Usage of Do Not Identify with remote Integration Server acting as an OAuth 2.0 Authorization Server:
*In CentraSite, when the parameter Identify Consumer is set to Do Not Identify, OAuth 2.0 validation occurs against a remote Integration Server, which acts as an OAuth 2.0 authorization server. But the application is NOT identified against the list of OAuth 2.0 consumer applications in CentraSite.
*In API Gateway, when a remote Integration Server acts as an OAuth 2.0 authorization server, each application in API Gateway creates an OAuth 2.0 client in the remote Integration Server. Any incoming request from the application is validated against the remote Integration Server, which acts as an OAuth 2.0 authorization server. Also, the application is identified against the list of registered applications in API Gateway.
*For the OAuth 2.0 clients in remote Integration Server that are not mapped to the OAuth 2.0 consumer applications in CentraSite, API Gateway offers a migration utility that uses the webMethods IS Service: pub.apigateway.migration.remoteOauth.migrateRemoteOauthClients.
This service creates an application for each OAuth 2.0 client that contains an associated scope-id that is same as that of the API ID in API Gateway, and registers the created application to that API. API Gateway checks for the presence of scope-id against the ID of all APIs.
Note:  
Software AG recommends you to invoke the webMethods IS Service only after you migrate all OAuth 2.0 APIs from CentraSite to API Gateway.
Pre-requisite: To run the webMethods IS Service is that a remote Integration Server should be configured as OAuth 2.0 authorization server in the Integration Server where API Gateway is running (in the Integration Server Administrator, go to Security -> Oauth -> Edit OAuth Global Settings -> Authorization server).
Evaluate WSS Username Token
You can secure SOAP APIs using client's WSS username token. This policy action:
*Identifies the application against either the Registered Applications list or the Global Applications list in API Gateway.
*Validates the client's WSS username token against the list of users in the Integration Server on which API Gateway is running.
The Evaluate WSS Username Token policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the following policies under the Identify & Access stage in API Gateway as follows:
*If this policy action is defined for an API in CentraSite, then the policy Inbound Authentication - Message is included to the API's policy list in API Gateway.
*If this policy action is set to identify the application (against a list of global or registered Applications) using the parameter Identify Consumer: Global Applications / Registered Applications, then the policy Identify & Authorize Application is included to the API's policy list in API Gateway.
*If this policy action is set to NOT identify the application (against a list of global or registered Applications) using the parameter Identify Consumer: Do Not Identify, then the policy Identify & Authorize Application is NOT included to the API's policy list in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Identify Consumer:
*Do Not Identify
Token Assertions:
*Require WSS Username token
When the parameter Identify Consumer is set to Do Not Identify in CentraSite, the policy Identify and Authorize Application that is used to identify an application is NOT included to the API's list of policies in API Gateway.
However, the policy Inbound Authentication - Message with the parameter Require WSS Username token that is used to enforce the SOAP message security is included to the API's list of policies in API Gateway.
Identify Consumer:
*Global Consumers
Application Lookup Condition:
*Global applications
Token Assertions:
*Require WSS Username token
When the parameter Identify Consumer is set to Global Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a global consumer application is included to the API's list of policies in API Gateway. The parameter Identification Type is set to WS Security Username token in the policy Identify and Authorize Application.
Also the policy Inbound Authentication - Message with the parameter Require WSS Username token that is used to enforce the SOAP message security is included to the API's list of policies in API Gateway.
Identify Consumer:
*Registered Consumers
Application Lookup Condition:
*Registered applications
Token Assertions:
*Require WSS Username token
When the parameter Identify Consumer is set to Registered Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a registered consumer application is included to the API's list of policies in API Gateway. The parameter Identification Type is set to Require WSS Username token in the policy Identify and Authorize Application.
Also the policy Inbound Authentication - Message with the parameter Require WSS Username token that is used to enforce the SOAP message security is included to the API's list of policies in API Gateway.
Evaluate WSS X.509 Certificate
You can secure SOAP APIs using client's x.509 certificate. This policy action:
*Identifies the application against either the Registered Applications list or the Global Applications list in API Gateway.
*Validates the client's x.509 certificate against the list of users the Integration Server on which API Gateway is running.
The Evaluate WSS X.509 Certificate policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the following policies under the Identify & Access stage in API Gateway as follows:
*If this policy action is defined for an API in CentraSite, then the policy Inbound Authentication - Message is included to the API's policy list in API Gateway.
*If this policy action is set to identify the application (against a list of global or registered Applications) using the parameter Identify Consumer: Global Applications / Registered Applications, then the policy Identify & Authorize Application is included to the API's policy list in API Gateway.
*If this policy action is set to NOT identify the application (against a list of global or registered Applications) using the parameter Identify Consumer: Do Not Identify, then the policy Identify & Authorize Application is NOT included to the API's policy list in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Identify Consumer:
*Do Not Identify
Token Assertions:
*Require X.509 Certificate
When the parameter Identify Consumer is set to Do Not Identify in CentraSite, the policy Identify and Authorize Application that is used to identify an application is NOT included to the API's list of policies in API Gateway.
However, the policy Inbound Authentication - Message with the parameter WS Security X.509 Certificate that is used to enforce the SOAP message security is included to the API's list of policies in API Gateway.
Identify Consumer:
*Global Consumers
Application Lookup Condition:
*Global applications
Token Assertions:
*Require X.509 Certificate
When the parameter Identify Consumer is set to Global Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a global consumer application is included to the API's list of policies in API Gateway. The parameter Identification Type is set to WS Security X.509 Certificate in the policy Identify and Authorize Application.
Also the policy Inbound Authentication - Message with the parameter Require X.509 Certificate that is used to enforce the SOAP message security is included to the API's list of policies in API Gateway.
Identify Consumer:
*Registered Consumers
Application Lookup Condition:
*Registered applications
Token Assertions:
*Require X.509 Certificate
When the parameter Identify Consumer is set to Registered Consumers in CentraSite, the policy Identify and Authorize Application that is used to identify a registered consumer application is included to the API's list of policies in API Gateway. The parameter Identification Type is set to WS Security X.509 Certificate in the policy Identify and Authorize Application.
Also the policy Inbound Authentication - Message with the parameter Require X.509 Certificate that is used to enforce the SOAP message security is included to the API's list of policies in API Gateway.
Require API Key Check
You can secure Web Service APIs using API Key authentication. This policy action identifies and validates the consumer against the list of registered applications in API Gateway.
The Require API Key Check policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the policy Identify & Authorize Application in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Not applicable
Identification Type:
*API Key
When the policy Require API Key Check is defined in CentraSite, the policy Identify and Authorize Application that is used to identify an application is included to the API's list of policies in API Gateway. The parameter Identification Type is set to API Key in the policy Identify and Authorize Application.
Require Encryption
You can secure SOAP APIs using encryption. This policy action mandates that an XML element of the SOAP request message must be encrypted.
The Require Encryption policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the policy Inbound Authentication - Message under the Identify & Access stage in API Gateway. The policy definition is mapped into the section Require Encryption.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Encrypt By: Element
Namespace:
*Prefix
Encrypted Elements
Namespace:
*Namespace Prefix
Encrypt By: Element
Namespace:
*URI
Encrypted Elements
Namespace:
*Namespace URI
Encrypt By: Element
*Element Required to be Encrypted
Encrypted Elements
*XPath
Encrypt By: Part
Encrypt Part
*Soap Body
Encrypted Parts
*Entire SOAP Body
*All SOAP Attachments
Encrypt By: Part
Encrypt SOAP headers
*Name
Encrypted Parts
SOAP Header:
*Header Name
Encrypt By: Part
Encrypt SOAP headers
*Namespace
Encrypted Parts
SOAP Header:
*Header Namespace
Require Signing
You can secure SOAP APIs using signature. This policy action mandates that an XML element of the SOAP request message must be signed.
The Require Signing policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the policy Inbound Authentication - Message under the Identify & Access stage in API Gateway. The policy definition is mapped into the section Require Signature.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Sign By: Element
Namespace:
*Prefix
Signed Elements
Namespace:
*Namespace Prefix
Sign By: Element
Namespace:
*URI
Signed Elements
Namespace:
*Namespace URI
Sign By: Element
*Element Required to be Signed
Signed Elements
*XPath
Sign By: Part
Sign Part
*Soap Body
Signed Parts
*Entire SOAP Body
*All SOAP Attachments
Sign By: Part
Sign SOAP headers
*Name
Signed Parts
SOAP Header:
*Header Name
Sign By: Part
Sign SOAP headers
*Namespace
Signed Parts
SOAP Header:
*Header Namespace
Require SSL
You can secure SOAP APIs using SSL. This policy action mandates that client certificates must be sent only over a two-way SSL connection .
The Require SSL policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the policy Require HTTP / HTTPS under the Transport stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Client Certificate Required (check box)
Protocol:
*HTTP
*HTTPS
*When the parameter Client Certificate Required check box is selected (set to true) in CentraSite, the policy Require HTTP / HTTPS with the parameter HTTPS is included (if not already included) to the API's list of policies in API Gateway.
*When the parameter Client Certificate Required check box is not selected (set to false) in CentraSite, the default policy Require HTTP / HTTPS with the default parameter HTTP is included to the API's list of policies in API Gateway.
Require Timestamps
You can secure SOAP APIs using timestamps. This policy action mandates that timestamp must be included in the SOAP message header.
The Require Timestamps policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the policy Inbound Authentication - Message under the Identify & Access stage in API Gateway. The policy definition is mapped into the section Require Timestamp.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Not applicable
Token Assertions:
*Require Timestamp
When the policy action Require Timestamps is included to the list of policies in a SOAP API, the corresponding policy Inbound Authentication - Message with the parameter Token Assertions set to Require Timestamp is included to the API's list of policies in API Gateway.
Require WSS SAML Token
You can secure SOAP APIs using WS-Security SAML tokens. This policy action uses a SAML assertion token to validate the applications.
The Require WSS SAML Token policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the policy Inbound Authentication - Message under the Identify & Access stage in API Gateway. The policy definition is mapped into the section Require SAML Token.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Token Assertions:
*Require SAML Token
When the policy action Require WSS SAML Token is included to the list of policies in a SOAP API, the corresponding policy Inbound Authentication - Message with the parameter Token Assertions set to Require SAML Token is included to the API's list of policies in API Gateway.
SAML Version:
*SAML 1.1
*SAML 2.0
SAML Version:
*SAML 1.1
*SAML 2.0
SAML Subject Confirmation: Bearer
*WS Trust Version
*VERSION_05_02
*VERSION_05_12
*Issuer Address
*Metadata Reference Address
*Key Size
*Request Security Token Template Parameters
*Key
*Value
SAML Subject Confirmation: Bearer of Token
*WS-Trust Version
*WS-Trust 1.0
*WS-Trust 1.3
*Encrypt Signature
*Issuer Address
*Metadata Reference Address
*Algorithm Suite
*Basic128
*Basic128Rsa15
*Basic128Sha256
*Basic128Sha256Rsa15
*Basic192
*Basic192Rsa15
*Basic192Sha256
*Basic192Sha256Rsa15
*Basic256
*Basic256Rsa15
*Basic256Sha256
*Basic256Sha256Rsa15
*TripleDe
*TripleDesRsa15
*TripleDesSha256
*Require Security Token Template Parameters
*Key
*Value
SAML Subject Confirmation: Holder of Key (Asymmetric)
*WS Trust Version
*VERSION_05_02
*VERSION_05_12
*Algorithm Suite
*Basic128
*Basic128Rsa15
*Basic128Sha256
*Basic128Sha256Rsa15
*Basic192
*Basic192Rsa15
*Basic192Sha256
*Basic192Sha256Rsa15
*Basic256
*Basic256Rsa15
*Basic256Sha256
*Basic256Sha256Rsa15
*TripleDe
*TripleDesRsa15
*TripleDesSha256
*Encrypt Signature
*Yes
*No
*Layout
*Lax
*LaxTsFirst
*LaxTsLast
*Strict
*Holder of Key Asymmetric Parameters
*Initiator Token Inclusion
*Always
*AlwaysToInitiator
*AlwaysToRecipient
*Never
*Once
*Recipient Token Inclusion
*Always
*AlwaysToInitiator
*AlwaysToRecipient
*Never
*Once
*Issuer Address
*Metadata Reference Address
*Key Size
*Request Security Token Template Parameters
*Key
*Value
SAML Subject Confirmation: Holder of Key - Public
*WS-Trust Version
*WS-Trust 1.0
*WS-Trust 1.3
*Encrypt Signature
*Issuer Address
*Metadata Reference Address
*Algorithm Suite
*Basic128
*Basic128Rsa15
*Basic128Sha256
*Basic128Sha256Rsa15
*Basic192
*Basic192Rsa15
*Basic192Sha256
*Basic192Sha256Rsa15
*Basic256
*Basic256Rsa15
*Basic256Sha256
*Basic256Sha256Rsa15
*TripleDe
*TripleDesRsa15
*TripleDesSha256
*Require Security Token Template Parameters
*Key
*Value
SAML Subject Confirmation: Holder of Key (Symmetric)
*WS Trust Version
*VERSION_05_02
*VERSION_05_12
*Algorithm Suite
*Basic128
*Basic128Rsa15
*Basic128Sha256
*Basic128Sha256Rsa15
*Basic192
*Basic192Rsa15
*Basic192Sha256
*Basic192Sha256Rsa15
*Basic256
*Basic256Rsa15
*Basic256Sha256
*Basic256Sha256Rsa15
*TripleDe
*TripleDesRsa15
*TripleDesSha256
*Encrypt Signature
*Yes
*No
*Layout
*Lax
*LaxTsFirst
*LaxTsLast
*Strict
*Holder of Key Symmetric Parameters
*Protection Token Inclusion
*Always
*AlwaysToInitiator
*AlwaysToRecipient
*Never
*Once
*Issuer Address
*Metadata Reference Address
*Key Size
*Request Security Token Template Parameters
*Key
*Value
SAML Subject Confirmation: Holder of Key - Symmetric
*WS-Trust Version
*WS-Trust 1.0
*WS-Trust 1.3
*Encrypt Signature
*Issuer Address
*Metadata Reference Address
*Algorithm Suite
*Basic128
*Basic128Rsa15
*Basic128Sha256
*Basic128Sha256Rsa15
*Basic192
*Basic192Rsa15
*Basic192Sha256
*Basic192Sha256Rsa15
*Basic256
*Basic256Rsa15
*Basic256Sha256
*Basic256Sha256Rsa15
*TripleDe
*TripleDesRsa15
*TripleDesSha256
*Require Security Token Template Parameters
*Key
*Value
Validate SAML Audience URIs
You can secure SOAP APIs using Audience URIs. This policy action verifies whether any of the audience URI within a valid condition element in SAML assertion matches with any of the configured URIs .
The Validate SAML Audience URIs policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the policy Inbound Authentication - Message under the Identify & Access stage in API Gateway. The policy definition is mapped into the section Validate SAML Audience URI.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Allowed URIs:
*URI
Allowed URIs:
*URI
Match Criteria:
*Allow Sublevels
Match Criteria:
*Allow Sublevels
Match Criteria:
*Exact Match
Match Criteria:
*Exact Match
Validate Schema
You can secure SOAP APIs using schema validation. This policy action validates XML request messages, response messages, or both, against the XML schema referenced in the API's WSDL.
The Validate Schema policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the policy Validate Schema under the Request Processing or Request Processing stage in API Gateway as follows:
*If this policy action is defined to validate SOAP request messages with the parameter Validate SOAP Message set to Request in CentraSite, then the policy Validate Schema under the Request Processing stage is included to the API's policy list in API Gateway.
*If this policy action is defined to validate SOAP response messages with the parameter Validate SOAP Message set to Response in CentraSite, then the policy Validate Schema under the Response Processing stage is included to the API's policy list in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Validate SOAP Message:
*Request
*Feature Name
*Feature Value:
*True
*False
When the parameter Validate SOAP Message is set to Request in CentraSite, the policy Validate Schema under Request Processing stage is included to the API's list of policies inAPI Gateway.
Validate SOAP Message:
*Response
*Feature Name
*Feature Value:
*True
*False
When the parameter Validate SOAP Message is set to Response in CentraSite, the policy Validate Schema under Response Processing stage is included to the API's list of policies inAPI Gateway.
HTTP Basic Authentication
This policy action uses basic HTTP authentication credentials to authenticate applications.
The HTTP Basic Authentication policy in CentraSite is mapped into the policy Outbound Authentication - Transport under the Routing stage in API Gateway. The parameter Authentication Scheme is set to Basic.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Authenticate Using:
Custom Credentials
*Username
*Password
*Domain
Authenticate using:
Custom Credentials
*Username
*Password
*Domain
Authenticate Using:
Secure Alias
*Alias Name
Authenticate scheme:
Alias
Authenticate Using:
Use Existing Credentials
Authenticate using:
Incoming HTTP basic auth credentials
NTLM Authentication
This policy action uses NTLM credentials to authenticate applications.
The NTLM Authentication policy in CentraSite is mapped into the policy Outbound Authentication - Transport under the Routing stage in API Gateway. The parameter Authentication Scheme is set to NTLM.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Authenticate Using:
Custom Credentials
*Username
*Password
*Domain
Authenticate using:
Custom Credentials
*Username
*Password
*Domain
Authenticate Using:
Secure Alias
*Alias Name
Authenticate scheme:
Alias
Authenticate Using:
Transparent
Authenticate using:
Transparent
Authenticate Using:
Use Existing Credentials
Authenticate using:
Incoming HTTP basic auth credentials
OAuth2 Authentication
This policy action uses basic OAuth 2.0 token credentials to authenticate applications.
The OAuth2 Authentication policy in CentraSite is mapped into the policy Outbound Authentication - Transport under the Routing stage in API Gateway. The parameter Authentication Scheme is set to OAuth2.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Authenticate Using:
Custom Token
*Custom Credential
*OAuth2 Token
Authenticate using:
Custom Credentials
*Custom credentials
*OAuth2 token
Authenticate Using:
Secure Alias
*Alias Name
Authenticate scheme:
Alias
Authenticate Using:
Use Existing Token
Authenticate using:
Incoming OAuth token
Kerberos Authentication
This policy action uses Kerberos token credentials to authenticate applications.
You can select the level at which the Kerberos authentication should be enforced for APIs:
*Message level
*Transport layer
The Kerberos Authentication policy action in CentraSite is mapped into the following policies in API Gateway. In both cases, the parameter Authentication Scheme is set to Kerberos.
*If this policy action is set to authenticate SOAP APIs at the message level using the parameter Enforcement Point: Message Level in CentraSite, then the policy Outbound Authentication - Message under the Routing stage is included to the API's policy list in API Gateway.
*If this policy action is set to authenticate SOAP and REST APIs at the transport layer using the parameter Enforcement Point: Transport Level in CentraSite, then the policy Outbound Authentication - Transport under the Routing stage is included to the API's policy list in API Gateway.
Enforcement Point: Message Level Security
The following table summarizes the mapping of the policy enforcement at the message level:
CentraSite
API Gateway
Notes
Authenticate Using:
Custom Credentials
*Client Principal
*Client Password
*Service Principal
*Service Principal Form
*hostbased
*username
Authenticate using:
Custom Credentials
*Client principal
*Client password
*Service principal
*Service principal nameform
*Username
*Hostbased
Authenticate Using:
Delegating Incoming Credentials
*Client Principal
*Client Password
*Service Principal
*Service Principal Form
*hostbased
*username
Authenticate using:
Delegating incoming credentials
*Client principal
*Client password
*Service principal
*Service principal nameform
*Username
*Hostbased
Authenticate Using:
Secure Alias
*Alias Name
Authenticate scheme:
Alias
Authenticate Using:
Use Existing Credentials
*Service Principal
*Service Principal Form
*hostbased
*username
Authenticate using:
Incoming HTTP basic auth credentials
*Service principal
*Service principal nameform
*Username
*Hostbased
Enforcement Point: Transport Layer Security
The following table summarizes the mapping of the policy enforcement at the transport layer:
CentraSite
API Gateway
Notes
Authenticate Using:
Custom Credentials
*Client Principal
*Client Password
*Service Principal
*Service Principal Form
*hostbased
*username
Authenticate using:
Custom Credentials
*Client principal
*Client password
*Service principal
*Service principal nameform
*Username
*Hostbased
Authenticate Using:
Delegating Incoming Credentials
*Client Principal
*Client Password
*Service Principal
*Service Principal Form
*hostbased
*username
Authenticate using:
Delegating incoming credentials
*Client principal
*Client password
*Service principal
*Service principal nameform
*Username
*Hostbased
Authenticate Using:
Secure Alias
*Alias Name
Authenticate scheme:
Alias
Authenticate Using:
Use Existing Credentials
*Service Principal
*Service Principal Form
*hostbased
*username
Authenticate using:
Incoming HTTP basic auth credentials
*Service principal
*Service principal nameform
*Username
*Hostbased
SAML Authentication
This policy action uses SAML token credentials to authenticate applications.
The SAML Authentication policy in CentraSite is mapped into the policy Outbound Authentication - Message under the Routing stage in API Gateway. The parameter Authentication Scheme is set to SAML.
The SAML Issuer Communication details in CentraSite are mapped into the SAML issuer configuration page (go to <Username> > Administration > Security > SAML issuer) in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Not applicable
Authenticate scheme:
Alias
Signing Alias
Signing configurations
*Keystore alias
*Key alias
This parameter refers to the authentication configurations that should be used for signing outbound messages.
The parameter Signing Alias of CentraSite is mapped in to the parameter Key alias in API Gateway.
The parameter Keystore alias is mapped in to the parameter Keystore alias as defined in the Keystore/Truststore configuration page (go to Username > Administration > General > Security) in API Gateway.
Encryption Alias
Encryption configurations
*Truststore alias
*Certificate alias
This parameter refers to the authentication configurations that should be used for encrypting outbound messages.
The parameter Encryption Alias of CentraSite is mapped in to the parameter Certificate alias in API Gateway.
The parameter Truststore alias is mapped in to the parameter Truststore alias as defined in the Keystore/Truststore configuration page (go to Username > Administration > General > Security) in API Gateway.
Issuer Communication
*Action
*Act as Delegation
*Normal Client
SAML Issuer Configuration
*Name
*Act as Delegation
*Normal Client
Issuer Communication
*Communicate Using: WSS Username (Message)
*WSS Username Configuration
*Username
*Password
SAML Issuer Configuration
*Communicate using: WSS Username
*Authenticate using: Custom credentials
*Username
*Password
Issuer Communication
*Communicate Using: Kerberos Over Transport (Message)
*Authentication Mode: Custom Credentials
*Client Principal
*Client Password
*Service Principal
*Service Principal Form
*Host Based
*Username
*Authentication Mode: Delegate Incoming Token
*Client Principal
*Client Password
*Service Principal
*Service Principal Form
*Host Based
*Username
SAML Issuer Configuration
*Communicate using: Kerberos
*Authenticate using: Custom Credentials
*Client Principal
*Client Password
*Service Principal
*Service Principal Form
*Username
*Hostbased
*Authenticate using: Delegate incoming credentials
*Client Principal
*Client Password
*Service Principal
*Service Principal Form
*Username
*Hostbased
*Authenticate using: Incoming HTTP basic auth credentials
*Service Principal
*Service Principal Form
*Username
*Hostbased
Endpoint
Endpoint URI
Applies to
Applies to
SAML Version
*SAML 1.1
*SAML 2.0
SAML Version
*SAML 1.1
*SAML 2.0
WS-Trust Version:
*VERSION_05_02
*VERSION_05_12
WS-Trust Version:
*WS-Trust 1.0
*WS-Trust 1.3
Signing Alias
Signing configurations:
*Keystore alias
*Key alias
This parameter refers to the authentication configurations that should be used for signing outbound messages.
The parameter Signing Alias of CentraSite is mapped in to the parameter Key alias in API Gateway.
The parameter Keystore alias is mapped in to the parameter Keystore alias as defined in the Keystore/Truststore configuration page (go to Username > Administration > General > Security) in API Gateway.
Encryption Alias
Encryption configurations:
*Truststore alias
*Certificate alias
This parameter refers to the authentication configurations that should be used for encrypting outbound messages.
The parameter Encryption Alias of CentraSite is mapped in to the parameter Certificate alias in API Gateway.
The parameter Truststore alias is mapped in to the parameter Truststore alias as defined in the Keystore/Truststore configuration page (go to Username > Administration > General > Security) in API Gateway.
Extended Parameters
*Key Size
*Key Type
*Signature Algorithm
*Encryption Algorithm
*CanonicalizationAlgorithm
*ComputedKeyAlgorithm
*Encryption
*ProofEncryption
*KeyWrapAlgorithm
*SignWith
*EncryptWith
Request security token template parameters:
*Key
*Value
Set Media Type (Request Handling)
This policy action specifies the content type for a REST request.
The Set Media Type policy action under the Request Handling accordion in CentraSite mapped into the policy Set Media Type under the Transport stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Media Type:
Default Content-Type:
Though this policy is listed in the Policy catalog of a SOAP API, it is applicable only for a REST enabled SOAP API in API Gateway.
Set Media Type (Response Processing)
This policy action specifies the content type for a REST response.
The Set Media Type policy action under the Response Processing accordion in CentraSite mapped into the policy Set Media Type under the Transport stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Media Type:
Default Accept Header:
Though this policy is listed in the Policy catalog of a SOAP API, it is applicable only for a REST enabled SOAP API in API Gateway.
Request Transformation
This policy action specifies the XSLT transformation file to transform request messages from applications into a format required by the native API in the SOAP request before it is submitted to the native API.
The Request Transformation policy action under the Request Handling accordion is mapped into the policy XSLT Transformation under the Request Processing stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Select Type: Transformation Alias
*Alias Name
XSLT Transformation Alias
Select Type: Transformation File
*Transformation File
XSLT Document
*XSLT File
*XSLT Features
*Feature Name
*Feature Value
Regardless of a XSLT file name, for example, PreProcessingXSLT.xsl defined in CentraSite, the XSLT file name is transformed into a default name, RequestProcessingXSLT_<X>.xsl in API Gateway. Here, X is an integer, which denotes the number of XSLT files that are mapped from CentraSite to API Gateway.
Let us consider an API contains two Request Transformation polices, each defined with an unique XSLT file, PreProcessingXSLT1.xsl and PreProcessingXSLT2.xsl in CentraSite. When this API is published from CentraSite to API Gateway, the two Request Transformation polices are mapped into a single Request Transformation policy in API Gateway. The XSLT file names are transformed as RequestProcessingXSLT_1.xsl and RequestProcessingXSLT_2.xsl in API Gateway.
Response Transformation
This policy action specifies the XSLT transformation file to transform response messages from native APIs into a format required by the application.
The Response Transformation policy action under the Response Processing accordion in CentraSite is mapped into the policy XSLT Transformation under the Response Processing stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Select Type: Transformation Alias
*Alias Name
XSLT Transformation Alias
Select Type: Transformation File
*Transformation File
XSLT Document
*XSLT File
*XSLT Features
*Feature Name
*Feature Value
Regardless of a XSLT file name, for example, PostProcessingXSLT.xsl defined in CentraSite, the XSLT file name is transformed into a default name, ResponseProcessingXSLT_<X>.xsl in API Gateway. Here, X is an integer, which denotes the number of XSLT files that are mapped from CentraSite to API Gateway.
Let us consider an API contains two Response Transformation polices, each defined with an unique XSLT file, PostProcessingXSLT1.xsl and PostProcessingXSLT2.xsl in CentraSite. When this API is published from CentraSite to API Gateway, the two Response Transformation polices are mapped into a single Response Transformation policy in API Gateway. The XSLT file names are transformed as ResponseProcessingXSLT_1.xsl and ResponseProcessingXSLT_2.xsl in API Gateway.
Invoke webMethods Integration Server (Request Handling)
This policy action pre-processes the request messages and transforms the message into a format required by the native API, before API Gateway sends the requests to native APIs .
The Invoke webMethods Integration Server policy action under the Response Processing accordion in CentraSite is mapped into the policy Invoke webMethods IS under the Request Processing stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Select Type: webMethods IS Service
*webMethods IS Service
webMethods IS Service
Select Type: webMethods IS Service Alias
*webMethods IS Service Alias
webMethods IS Service
Invoke webMethods Integration Server (Response Processing)
This policy action pre-processes the native API's response messages into a format required by the application, before API Gateway returns the responses to the application .
The Invoke webMethods Integration Server policy action under the Response Processing accordion in CentraSite is mapped into the policy Invoke webMethods IS under the Response Processing stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Select Type: webMethods IS Service
*webMethods IS Service
webMethods IS Service
Select Type: webMethods IS Service Alias
*webMethods IS Service Alias
webMethods IS Service
Conditional Error Processing
This policy action returns the custom error message (and the native provider's service fault content) to the application when the native provider returns the service fault.
The Conditional Error Processing policy action under the Error Handling accordion in CentraSite is mapped into the policy Conditional Error Processing under the Error Handling stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Error Conditions
Type: HTTP Header
*Header Name
*Header Value
Error Conditions
Type: Header Error Criteria
*Header Name
*Header Value
Error Conditions
Type: Status Code
*Code
Error Conditions
Type: Status Code Error Criteria
*Code
Error Conditions
Type: XPath Expression
*XPath Expression
*Namespaces
*Prefix
*URI
*Value
Error Conditions
Type: XPath Expression
*XPath Expression
*Namespace
*Namespace Prefix
*Namespace URI
*Value
Pre-Processing
Type: ESB
*webMethods IS Service
Pre-Processing
Type: Invoke webMethods Integration Server Service
*webMethods IS Service
Pre-Processing
Type: XSLT
*Transformation File
Pre-Processing
Type: XSLT Transformation
XSLT Document
*XSLT File
*XSLT Features
*Feature Name
*Feature Value
Failure Message
Content Type
*json
*text
*xml
Error Template
Use as default (check box)
Failure Message
Failure Messages
*json
*text
*xml
Error Template
Use as default (check box)
Custom Error Variable
Payload Type
*Request
*Response
Name
XPath Expression
Namespaces
*Prefix
*URI
Custom Error Variable
Payload Type
*Request
*Response
Name
XPath Expression
Namespaces
*Namespace Prefix
*Namespace URI
Post-processing
Type: XSLT
*Transformation File
Pre-Processing
Type: XSLT Transformation
XSLT Document
*XSLT File
*XSLT Features
*Feature Name
*Feature Value
Send Native Provider Fault Message (check box)
Send Native Provider Fault Message (check box)
Require HTTP/HTTPS
This policy action specifies the HTTP and HTTPS protocol and the SOAP format for an API to accept and process the requests.
The Require HTTP / HTTPS policy action under the Request Handling > Protocol accordion in CentraSite is mapped into the policy HTTP / HTTPS under the Transport stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Protocol
*HTTP
*HTTPS
Protocol
*HTTP
*HTTPS
When the policy Require SSL is included to the API's policy list in CentraSite, the parameter HTTPS is selected in API Gateway.
SOAP Version
*SOAP 1.1
*SOAP 1.2
SOAP version
*SOAP 1.1
*SOAP 1.2
Require JMS
This policy action specifies the JMS protocol and the SOAP format for an API to accept and process the requests.
The Require JMS policy action under the Request Handling > Protocol accordion in CentraSite is mapped into the policy Require JMS under the Transport stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
JMS Trigger
JMS Provider Endpoint Alias
When the policy Require SSL is included to the API's policy list in CentraSite, the parameter HTTPS is selected in API Gateway.
SOAP Version
*SOAP 1.1
*SOAP 1.2
SOAP version
*SOAP 1.1
*SOAP 1.2
Enable REST Support
When a SOAP API with this policy action is published from CentraSite to API Gateway, API Gateway Deployer Service looks for the expose-as-rest policy element in the inSequence of the Virtual Service Definition (VSD).
The following example shows the inSequence of a VSD holding the policy element expose-as-rest:
<inSequence>
<expose-as-rest soap-version="soap11"/>
<http-config>
<authentication mode="anonymous"/>
</http-config>
<send>
<endpoint>
<address isAlias="false" optimize="none" passSecurityHeaders="false"
uri="https://test:8081/bayern/services/
BayernService.BayernServiceHttpsEndpoint/">
<connect-timeout>
<duration>30&lt;/duration>
</connect-timeout>
</address>
</endpoint>
</send>
</inSequence>
If the inSequence of the VSD holds the policy element expose-as-rest, then the API Gateway Deployer Service sets the isRESTInvokeEnabled flag to true for all operations of the SOAP API.
JMS Routing Rule
This policy action specifies the JMS provider queue to which the API Gateway submits the request, and the destination to which the API Gateway waits for the native SOAP API to return the response.
The JMS Routing Rule policy action under the Policy Enforcement > JMS Routing accordion in CentraSite is mapped into the policy JMS Routing under the Routing stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Connection URL
Connection URL
Destination Name
Reply to Destination
Priority
Priority
Timeout (ms)
Timeout (ms)
Delivery Mode
*Non Persistent
*Persistent
Delivery Mode
*Non Persistent
*Persistent
Set Message Properties
This policy action specifies the JMS message properties that are to be sent to the native SOAP APIs.
The Set Message Properties policy action under the Policy Enforcement > JMS Routing accordion in CentraSite is mapped into the policy JMS Properties under the Routing stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Property
Name
JMS Property
JMS Property Key
Property
Value
JMS Property
JMS Property Value
Set JMS Headers
This policy action specifies the JMS headers that are to be sent to the to the native SOAP APIs.
The Set JMS Headers policy action under the Policy Enforcement > JMS Routing accordion in CentraSite is mapped into the policy JMS Properties under the Routing stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Header
Name
JMS Property
JMS Property Key
Header
Value
JMS Property
JMS Property Value
Log Invocation
This policy action enables logging of the incoming requests along with the request and response payloads to a specified destination.
The Log Invocation policy action under the Policy Enforcement > Logging and Monitoring accordion in CentraSite is mapped into the policy Log Invocation under the Traffic Monitoring stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Payloads
*Request
*Response
*Store Request Payload
*Store Response Payload
*Compress Payload Data
Log Generation Frequency
*Always
*On Failure
*On Success
Log Generation Frequency
*Always
*On Failure
*On Success
Send Log Data
*API Portal
*Audit Log
*CentraSite
*EDA / Database
*ElasticSearch
*E-mail
*Local Log
*SNMP
Send Log Data
*API Gateway
*API Portal
*Audit Log
*CentraSite
*Digital Events
*Elasticsearch
*E-mail
*JDBC
*Local Log: Log Level
*Error
*Info
*Warn
*SNMP
*Beginning with version 10.1, API Gateway supports the following destinations:
*Audit Log
*CentraSite
*Digital Events
*Elasticsearch
*Email
*Local Log
*SNMP
*The destination name for database is changed from EDA / Database in CentraSite to JDBC in API Gateway. Therefore, when the parameter Send Log Data is set to EDA / Database in CentraSite, the pool alias definition and the corresponding configurations are mapped into JDBC in API Gateway.
*When the EDA / Database destination is selected in CentraSite, it also automatically selects the Digital Events destination in API Gateway.
Monitor Service Performance
This policy action monitors the run-time performance conditions for an API, and sends alerts to a specified destination when the performance conditions are violated. However, this policy action monitors run-time performance for all applications.
The Monitor Service Performance policy action under the Policy Enforcement > Logging and Monitoring accordion in CentraSite is mapped into the policy Monitor Service Performance under the Traffic Monitoring stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Action Configuration: Name
*Availability
*Average Response Time
*Fault Count
*Maximum Response Time
*Minimum Response Time
*Successful Request Count
*Total Request Count
Action Configuration: Name
*Availability
*Average Response Time
*Fault Count
*Maximum Response Time
*Minimum Response Time
*Successful Count
*Total Request Count
Action Configuration: Operator
*Equal To
*Greater Than
*Less Than
Action Configuration: Operator
*Equal To
*Greater Than
*Less Than
Action Configuration: Value
Action Configuration: Value
Alert Parameters: Alert Interval (minutes)
Alert Interval:
Unit:
*Minutes
*Hours
*Days
*Weeks
Alert for Consumer Applications
Consumer Applications
Names of the Consumer Applications in CentraSite are transformed into Application IDs in API Gateway.
Alert Parameters: Alert Destination
*API Portal
*CentraSite
*EDA/Database
*Elasticsearch
*E-mail
*Local Log: Log Level
*Error
*Info
*Warn
*SNMP
Alert Destination
*API Gateway
*API Portal
*CentraSite
*Digital Events
*Elasticsearch
*Email
*JDBC
*Local Log: Log Level
*Error
*Info
*Warn
*SNMP
*Beginning with version 10.1, API Gateway supports the following destinations:
*Audit Log
*CentraSite
*Digital Events
*Elasticsearch
*Email
*Local Log
*SNMP
*The destination name for database is changed from EDA / Database in CentraSite to JDBC in API Gateway. Therefore, when the parameter Send Log Data is set to EDA / Database in CentraSite, the pool alias definition and the corresponding configurations are mapped into JDBC in API Gateway.
*When the EDA / Database destination is selected in CentraSite, it also automatically selects the Digital Events destination in API Gateway.
Alert Parameters: Alert Message
Alert Message
Monitor Service Level Agreement
This policy action monitors the user-specified set of run-time performance conditions for an API, and sends alerts to a specified destination when the performance conditions are violated. This policy action monitors run-time performance for one or more specified applications.
The Monitor Service Level Agreement policy action under the Policy Enforcement > Logging and Monitoring accordion in CentraSite is mapped into the policy Monitor Service Level Agreement under the Traffic Monitoring stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Actions: Name
*Availability
*Average Response Time
*Fault Count
*Maximum Response Time
*Minimum Response Time
*Successful Request Count
*Total Request Count
Action Configuration: Name
*Availability
*Average Response Time
*Fault Count
*Maximum Response Time
*Minimum Response Time
*Successful Count
*Total Request Count
The Soft Limit configuration of Throttling Traffic Optimization policy action under the Policy Enforcement > Traffic Management accordion in CentraSite is mapped into this policy in API Gateway.
Actions: Operator
*Equal To
*Greater Than
*Less Than
Action Configuration: Operator
*Equal To
*Greater Than
*Less Than
Actions: Value
Action Configuration: Value
Alert Parameters: Alert Interval (minutes)
Alert Interval
Unit
*Minutes
*Hours
*Days
*Weeks
Alert for Consumer Applications
Consumer Applications
Names of the consumer applications in CentraSite are transformed into Application IDs in API Gateway.
As a pre-requisite the appropriate consumer applications should be migrated from CentraSite toAPI Gateway.
Alert Parameters: Alert Frequency
*Every Time
*Only Once
Alert Frequency
*Every Time
*Only Once
Alert Parameters: Alert Destination
*API Portal
*CentraSite
*EDA/Database
*Elasticsearch
*E-mail
*Local Log: Log Level
*Error
*Info
*Warn
*SNMP
Alert Destination
*API Gateway
*API Portal
*CentraSite
*Digital Events
*Elasticsearch
*Email
*JDBC
*Local Log: Log Level
*Error
*Info
*Warn
*SNMP
*Beginning with version 10.1, API Gateway supports the following destinations:
*Audit Log
*CentraSite
*Digital Events
*Elasticsearch
*Email
*Local Log
*SNMP
*The destination name for database is changed from EDA / Database in CentraSite to JDBC in API Gateway. Therefore, when the parameter Send Log Data is set to EDA / Database in CentraSite, the pool alias definition and the corresponding configurations are mapped into JDBC in API Gateway.
*When the EDA / Database destination is selected in CentraSite, it also automatically selects the Digital Events destination in API Gateway.
Alert Parameters: Alert Message
Alert Message
Straight Through Routing
This policy action routes requests directly to a native endpoint that you specify.
The Straight Through Routing policy action under the Policy Enforcement > Routing accordion in CentraSite is mapped into the policy Straight Through Routing under the Routing stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Route To:
Endpoint URI:
Endpoint Properties: SOAP Optimization Method
*MTOM
*None
*SWA
SOAP Optimization Method:
*MTOM
*None
*SWA
Endpoint Properties: HTTP Connection Timeout (seconds)
HTTP Connection Timeout (seconds)
Endpoint Properties: Read Timeout (seconds)
Read Timeout (seconds)
Endpoint Properties: SSL Configuration
*Client Certificate Alias
*Keystore Alias
SSL Configuration
*Keystore Alias
*Key Alias
Endpoint Properties: WS-Security Header
*Pass all security headers
*Remove processed security headers
Pass WS-Security Headers (check box)
*When the parameter WS-Security Header is set to Pass all security headers in CentraSite, the parameter Pass WS-Security Headers is selected in API Gateway.
*When the parameter WS-Security Header is set to Remove processed security headers in CentraSite, the parameter Pass WS-Security Headers is NOT selected in API Gateway.
Content Based Routing
This policy action routes specific types of messages to specific endpoints based on specific values that appear in the request message, if the native API is hosted at two or more endpoints. The requests are routed according to the content-based routing rules you define.
The Content Based Routing policy action under the Policy Enforcement > Routing accordion in CentraSite is mapped into the policy Content-based Routing under the Routing stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Route To:
Default Route To: Endpoint URI
Endpoint Properties: SOAP Optimization Method
*MTOM
*None
*SWA
Default Route To : SOAP Optimization Method
*MTOM
*None
*SWA
Endpoint Properties: HTTP Connection Timeout (seconds)
Default Route To : HTTP Connection Timeout (seconds)
Endpoint Properties: Read Timeout (seconds)
Default Route To : Read Timeout (seconds)
Endpoint Properties: SSL Configuration
*Client Certificate Alias
*Keystore Alias
Default Route To: SSL Configuration
*Keystore Alias
*Key Alias
Endpoint Properties: WS-Security Header
*Pass all security headers
*Remove processed security headers
Default Route To : Pass WS-Security Headers (check box)
*When the parameter WS-Security Header is set to Pass all security headers in CentraSite, the parameter Pass WS-Security Headers is selected in API Gateway.
*When the parameter WS-Security Header is set to Remove processed security headers in CentraSite, the parameter Pass WS-Security Headers is NOT selected in API Gateway.
Not applicable
Rules : Name
Regardless of a rule name, for example, Custom Rule, defined in CentraSite, the rule name is transformed into a default name, Rule <X> in API Gateway. Here, X is an integer, which denotes the number of rules that are mapped from CentraSite to API Gateway.
Let us consider an API contains the Context Based Routing policy action with two routing rules, each defined with an unique name, Custom Rule A and Custom Rule B in CentraSite. When this API is published from CentraSite to API Gateway, the two routing rules are mapped into the policy Context-based Routing in API Gateway. The rule names are transformed as Rule 1 and Rule 2 in API Gateway.
Routing Rule: XPath Expression
Rules: XPath Expression
Routing Rule: Namespace
*Prefix
*URI
Rules: Namespace
*Namespace Prefix
*Namespace URI
Routing Rule: Route To
Rules: Route To
Load Balancing and Failover Routing
This policy action routes the requests across multiple endpoints, if the native API is hosted at two or more endpoints.
The Load Balancing and Failover Routing policy action under the Policy Enforcement > Routing accordion in CentraSite is mapped into the policy Load Balancer Routing under the Routing stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Route To:
Endpoint URI
Endpoint Properties: SOAP Optimization Method
*MTOM
*None
*SWA
SOAP Optimization Method
*MTOM
*None
*SWA
Endpoint Properties: HTTP Connection Timeout (seconds)
HTTP Connection Timeout (seconds)
Endpoint Properties: Read Timeout (seconds)
Read Timeout (seconds)
Endpoint Properties: SSL Configuration
*Client Certificate Alias
*Keystore Alias
SSL Configuration
*Keystore Alias
*Key Alias
Endpoint Properties: WS-Security Header
*Pass all security headers
*Remove processed security headers
Pass WS-Security Headers (check box)
*When the parameter WS-Security Header is set to Pass all security headers in CentraSite, the parameter Pass WS-Security Headers is selected in API Gateway.
*When the parameter WS-Security Header is set to Remove processed security headers in CentraSite, the parameter Pass WS-Security Headers is NOT selected in API Gateway.
Timeout (seconds)
Suspend duration (seconds)
Set Custom Headers
This policy action specifies the HTTP headers to authenticate application's requests before submitting to the native SOAP APIs.
The Set Custom Headers policy action under the Policy Enforcement > Routing accordion in CentraSite is mapped into the policy Custom HTTP Header under the Routing stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Header
Name
HTTP Header
HTTP Header Key
Header
Value
HTTP Header
HTTP Header Value
Context Based Routing
This policy action routes specific types of messages to specific endpoints based on specific values that appear in the request message, if the native API is hosted at two or more endpoints. The requests are routed according to the context-based routing rules you define.
The Context Based Routing policy action under the Policy Enforcement > Routing accordion in CentraSite is mapped into the policy Context-based Routing under the Routing stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Route To:
Default Route To: Endpoint URI
Endpoint Properties: SOAP Optimization Method
*MTOM
*None
*SWA
Default Route To : SOAP Optimization Method
*MTOM
*None
*SWA
Endpoint Properties: HTTP Connection Timeout (seconds)
Default Route To : HTTP Connection Timeout (seconds)
Endpoint Properties: Read Timeout (seconds)
Default Route To : Read Timeout (seconds)
Endpoint Properties: SSL Configuration
*Client Certificate Alias
*Keystore Alias
Default Route To: SSL Configuration
*Keystore Alias
*Key Alias
Endpoint Properties: WS-Security Header
*Pass all security headers
*Remove processed security headers
Default Route To : Pass WS-Security Headers (check box)
*When the parameter WS-Security Header is set to Pass all security headers in CentraSite, the parameter Pass WS-Security Headers is selected in API Gateway.
*When the parameter WS-Security Header is set to Remove processed security headers in CentraSite, the parameter Pass WS-Security Headers is NOT selected in API Gateway.
Routing Rule : Name
Rules : Name
Regardless of a rule name, for example, Custom Rule, defined in CentraSite, the rule name is transformed into a default name, Rule <X> in API Gateway. Here, X is an integer, which denotes the number of rules that are mapped from CentraSite to API Gateway.
Let us consider an API contains the Context Based Routing policy action with two routing rules, each defined with an unique name, Custom Rule A and Custom Rule B in CentraSite. When this API is published from CentraSite to API Gateway, the two routing rules are mapped into the policy Context-based Routing in API Gateway. The rule names are transformed as Rule 1 and Rule 2 in API Gateway.
Not applicable
Rules: Condition Operator
*Or
*And
Routing Rule: Condition
*Variable
*Consumer
*Custom Context Variable
*Date
*IP Address
*IPv6 Address
*Predefined Context Variable
*Time
*Consumer
Rules: Condition
*Variable
*Consumer
*Date
*IPV4
*IPV6
*Predefined Context Variable
*Custom Context Variable
*Time
*Variable Value
*Beginning with version 10.1, API Gateway supports custom context variables in a routing rule that you create.
The custom context variable name in CentraSite is automatically prefixed with mx: in API Gateway.
*For a list of the predefined context variables, see below.
Routing Rule: Route To
Rules: Route To
The Predefined Context Variables
Display Name in CentraSite
Display Name in API Gateway
Average Response Time
Not applicable
Fault Count
Not applicable
Minimum Response Time
Not applicable
Maximum Response Time
Not applicable
Success Count
Not applicable
Total Count
Not applicable
Client IP Address
Inbound IP
Consumer
Consumer
Inbound Content Type
Inbound Content Type
Inbound HTTP Method
Inbound HTTP Method
Inbound Protocol
Inbound Protocol
Mediator Hostname
Gateway Hostname
Mediator IP Address
Gateway IP
Mediator Target Name
Not applicable
Native Service Provider Error
Not applicable
Native Service Response Message
Not applicable
Outbound HTTP Method
Routing Method
User
User
Virtual Service Name
Not applicable
Virtual Service Operation
Operation Name
Virtual Service URI
Inbound Request URI
Not applicable
Inbound Accept
Dynamic Routing
This policy action routes the requests to dynamic endpoints based on specific criteria that you specify.
The Dynamic Routing policy action under the Policy Enforcement > Routing accordion in CentraSite is mapped into the policy Dynamic Routing under the Routing stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Route using:
*Context Variable
*Header
*Header Name
Rule: Route Using
*Context
*Header
*Header Name
Route Through
Default Route To: Endpoint URI
Default Route-To
Route To
Endpoint Properties: SOAP Optimization Method
*MTOM
*None
*SWA
Default Route To: SOAP Optimization Method
*MTOM
*None
*SWA
Endpoint Properties: HTTP Connection
Timeout (seconds)
Default Route To: HTTP Connection
Timeout (seconds)
Endpoint Properties: Read Timeout (seconds)
Default Route To: Read Timeout (seconds)
Endpoint Properties: SSL Configuration
*Client Certificate Alias
*Keystore Alias
Default Route To: SSL Configuration
*Keystore Alias
*Key Alias
Endpoint Properties: WS-Security Header
*Pass all security headers
*Remove processed security headers
Default Route To: Pass WS-Security Headers (check box)
*When the parameter WS-Security Header is set to Pass all security headers in CentraSite, the parameter Pass WS-Security Headers is selected in API Gateway.
*When the parameter WS-Security Header is set to Remove processed security headers in CentraSite, the parameter Pass WS-Security Headers is NOT selected in API Gateway.
Authorize User
This policy action authorizes applications against a list of users and a list of groups registered in CentraSite or API Gateway.
The Authorize User policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the policy Authorize User under the Identify & Access stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Perform authorization against: List of users
*Users
List of Users
Perform authorization against: List of groups
*Groups
List of Groups
Allow Anonymous Usage
This policy action specifies whether to allow all users to access the API without restriction.
The Allow Anonymous Usage policy action under the Policy Enforcement > Security accordion in CentraSite is mapped into the policy Identify & Authorize Application under the Identify & Access stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Allow Anonymous Usage
*True
*False
Allow anonymous
*When the parameter Allow Anonymous Usage is set to True in CentraSite, the parameter Allow anonymous is selected in API Gateway.
*When the parameter Allow Anonymous Usage is set to False or if the policy action is NOT defined in CentraSite, the parameter Allow anonymous is NOT selected in API Gateway.
Throttling Traffic Optimization
This policy action limits the number of API invocations during a specified time interval, and sends alerts to a specified destination when the performance conditions are violated. This action avoids overloading the back-end APIs and their infrastructure, to limit specific applications in terms of resource usage, and so on.
The Throttling Traffic Optimization policy action under the Policy Enforcement > Traffic Management accordion in CentraSite is mapped into the policy Throttling Traffic Optimization under the Traffic Monitoring stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Hard Limit: Rule Name
*Total Request Count
Limit Configuration: Rule Name
*Total Request Count
Hard Limit: Operator
*Greater Than
Limit Configuration: Operator
*Greater Than
Hard Limit: Value
Limit Configuration: Value
Hard Limit: Alert Message for Hard Limit
Alert Message
Soft Limit : Rule Name
*Total Request Count
Action Configuration: Name
*Total Request Count
Depending on the value specified for the parameter Consumer Applications, the Soft Limit configuration of this policy action in CentraSite is mapped into one of the following policies under the Traffic Monitoring stage in API Gateway:
*If the value is set to a specific consumer, then this configuration is mapped into the policy Monitor Service Level Agreement.
*If the value is set to Any consumer application, then this configuration is mapped into the policy Monitor Service Performance.
Soft Limit : Operator
*Greater Than
Action Configuration: Operator
*Greater Than
Soft Limit : Value
Action Configuration: Value
Soft Limit : Alert Message for Hard Limit
Alert Message
Consumer Applications
Consumer Applications
Names of the consumer applications in CentraSite are transformed into Application IDs in API Gateway.
Interval Value
*Minutes
*Hours
*Days
*Weeks
Alert Interval
Unit:
*Minutes
*Hours
*Days
*Weeks
Frequency
*Every Time
*Only Once
Alert Frequency
*Every Time
*Only Once
Alert Destination
*API Portal
*CentraSite
*EDA/Database
*Elasticsearch
*E-mail
*Local Log: Log Level
*Error
*Info
*Warn
*SNMP
Alert Destination
*API Gateway
*API Portal
*CentraSite
*Digital Events
*Elasticsearch
*E-mail
*JDBC
*Local Log: Log Level
*Error
*Info
*Warn
*SNMP
*Beginning with version 10.1, API Gateway supports the following destinations:
*Audit Log
*CentraSite
*Digital Events
*Elasticsearch
*Email
*Local Log
*SNMP
*The destination name for database is changed from EDA / Database in CentraSite to JDBC in API Gateway. Therefore, when the parameter Send Log Data is set to EDA / Database in CentraSite, the pool alias definition and the corresponding configurations are mapped into JDBC in API Gateway.
*When the EDA / Database destination is selected in CentraSite, it also automatically selects the Digital Events destination in API Gateway.
Service Result Cache
This policy action enables caching of the results of SOAP and REST API invocations based on specific criteria that you specify.
The Service Result Cache policy action under the Policy Enforcement > Traffic Management accordion in CentraSite is mapped into the policy Service Result Cache under the Traffic Monitoring stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Configure Caching based on: HTTP Header
*Header Name
*Add to Whitelist
*Whitelist (Cache only for these values)
Cache Criteria: HTTP Header
*Cache responses only for these values
Configure Caching based on: Path
No cache criteria
If none of the cache criteria is specified, then API Gateway internally uses the Path criteria for caching the API response.
Configure Caching based on: XPath Expression
*Namespace
*Prefix
*URI
*XPath Expression
*Add to Whitelist
*Whitelist (Cache only for these values)
Cache Criteria: XPath Expression
*Namespace
*Prefix
*URI
*XPath Expression
*Cache responses only for these values
Not applicable
Cache Criteria: Query Parameters
*Parameter Name
*Cache responses only for these values
Time to Live (e.g., 5d 4h 1m)
Time to Live (e.g.,5d 4h 1m)
Maximum Response Payload Size (in KB, -1 = unlimited)
Maximum Response Payload Size (in KB)
Identify Consumer (CentraSite Control)
A legacy policy action from version 8.2.2. This policy action:
*Identifies an application based on the kind of consumer identifier (IP address, HTTP authorization token, and so on.) you specify.
*Allows anonymous users to access the API.
The Identify Consumer action defined in a runtime policy in CentraSite Control and enforced on an API in CentraSite Business UI is mapped into the policy Identify and Authorize Application under the Identify & Access stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Anonymous Usage Allowed
*Yes
*No
Allow anonymous
*When the parameter Anonymous Usage Allowed is set to Yes in CentraSite, the parameter Allow anonymous is selected (set to True) in the policy Identify and Authorize Application.
*When the parameter Anonymous Usage Allowed is set to No in CentraSite, the parameter Allow anonymous is NOT selected (set to False) in the policy Identify and Authorize Application.
Identify User Using
*IP Address
Identification Type
*IP Address Range
Identify User Using
*Token Derived from Host Name
Identification Type
*Hostname Address
Identify User Using
*Token Derived from HTTP Header
Identification Type
*HTTP Basic Authentication
Identify User Using
*Token Derived from WSS Header
Identification Type
*WS Security Username token
Identify User Using
*Token Derived from Custom XPATH
Identification Type
*XPath expression
Identify User Using
*Consumer Certificate
Identification Type
*WS Security X.509 Certificate
Identify User Using
*Client Certificate for SSL Connectivity
Identification Type
*SSL Certificate
Note:  
If this policy action is configured with Authorize Against Registered Consumer in CentraSite Control, the parameter Application Lookup Condition is set to Registered applications in the policy Identify and Authorize Application in API Gateway. If this policy action is NOT configured with Authorize Against Registered Consumer in CentraSite Control, then the parameter Application Lookup Condition is set to Global applications in the policy Identify and Authorize Application in API Gateway.
Authorize Against Registered Consumer (CentraSite Control)
A legacy policy action from version 8.2.2. This policy action authorizes requests against the Registered Applications list in API Gateway.
The Authorize Against Registered Consumer action defined in a runtime policy in CentraSite Control and enforced on an API in CentraSite Business UI is mapped into the policy Identify and Authorize Application under the Identify & Access stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Not applicable
Application Lookup Condition:
*Registered applications
The parameter Application Lookup Condition is set to Registered applications in the policy Identify and Authorize Application.
Note:  
This policy action is dependent on the Identify Consumer action in CentraSite Control.
Require HTTP Basic Authentication (CentraSite Control)
You can secure Web Service APIs using HTTP basic authentication. This policy action validates the client's credentials contained in the request's Authorization header against the list of users in the Integration Server on which API Gateway is running.
The Require HTTP Basic Authentication action defined in a runtime policy in CentraSite Control and enforced on an API in CentraSite Business UI is mapped into the policy Inbound Authentication - Transport under the Identify & Access stage in API Gateway.
The following table summarizes the mapping of this policy action:
CentraSite
API Gateway
Notes
Authentication Required
HTTP Basic Authentication
When the parameter Authentication Required is selected in CentraSite, the parameter HTTP Basic Authentication is selected (set to True) in the policy Inbound Authentication - Transport.
Copyright © 2015- 2017 Software AG, Darmstadt, Germany.
Product LogoContact Support   |   Community   |   Feedback