CentraSite Documentation : Runtime Governance with CentraSite : Run-Time Governance Reference : Built-In Run-Time Actions Reference for Virtual Services : Run-Time Actions Reference for Virtual Services : Identify Consumer
Identify Consumer
Mediator uses this action to identify consumer applications based on the kind of consumer identifier (IP address, HTTP authorization token, and so on.) you specify. Alternatively, this action provides an option to allow anonymous users to access the assets.
Input Parameters
Anonymous Usage Allowed
Boolean. Specifies whether to allow all users to access the asset, without restriction.
Value
Description
False
Default. Allows only the users specified in the Identify User Using parameter to access the assets.
True
Allow all users to access the asset. In this case, do not configure the Identify User Using parameter.
Identify User Using
String. Specifies the kind of consumer identifier that the action will use to identify consumer applications.
Value
Description
IP Address
Identifies one or more consumer applications based on their originating IP addresses.
Host Name
Identifies consumer applications based on a host name.
HTTP Authentication Token
Uses HTTP Basic authentication to verify the consumer's authentication credentials contained in the request's Authorization header. Mediator authorizes the credentials against the list of consumers available in the Integration Server on which Mediator is running. This type of consumer authentication is referred to as “preemptive authentication”. If you want to use “preemptive authentication”, you should also include the action Require HTTP Basic Authentication in the policy.
If you choose to omit “Require HTTP Basic Authentication”, the client will be presented with a security challenge. If the client successfully responds to the challenge, the user is authenticated. This type of consumer authentication is referred to as “non-preemptive authentication”. For more information, see Require HTTP Basic Authentication.
Note:  
If you select the value HTTP Authentication Token, do not include the Authorize Against Registered Consumers action in the policy. This is an invalid combination.
WS-Security Authentication Token
Validate user names and passwords that are transmitted in the SOAP message header in the WSS Username Token. If you select this value, you should also include the action Require WSS Username Token in the policy.
Custom Identification
Validates consumer applications based on an XML element (represented by an XPath expression).
Consumer Certificate
Identifies consumer applications based on information in a WSS X.509 certificate. If you select this value, you should also include the action Require WSS X.509 Token or the action Require Signing in the policy.
Client Certificate for SSL Connectivity
Validates the client's certificate that the consumer application submits to the asset in CentraSite. The client certificate that is used to identify the consumer is supplied by the client to the Mediator during the SSL handshake over the transport layer. In order to identify consumers by transport-level certificates, the run-time communication between the client and the Mediator must be over HTTPS and the client must pass a valid certificate.
To use this option, the following prerequisites must be met:
*In Integration Server, create a keystore and truststore, as described in webMethods Integration Server Administrator’s Guide.
*In Integration Server, create an HTTPS port, as described in webMethods Integration Server Administrator’s Guide.
*Configure Mediator by setting the IS Keystore and IS Truststore parameters, as described in t Administering webMethods Mediator.
*Configure Mediator by setting the HTTPS Ports Configuration parameter, as described in Administering webMethods Mediator.
When deciding which type of identifier to use to identify a consumer application, consider the following points:
*Whatever identifier you choose to identify a consumer application, it must be unique to the application. Identifiers that represent user names are often not suitable because the identified users might submit requests for multiple applications.
*Identifying applications by IP address or host name is often a suitable choice, however, it does create a dependency on the network infrastructure. If a consumer application moves to a new machine, or its IP address changes, you must update the identifiers in the application asset.
*Using X.509 certificates or a custom token that is extracted from the SOAP or XML message itself (using an XPATH expression), is often the most trouble-free way to identify a consumer application.
Copyright © 2005-2016 Software AG, Darmstadt, Germany.
Product LogoContact Support   |   Community   |   Feedback