CentraSite 10.5 | CentraSite User’s Guide | Runtime Governance | Consumer Management
 
Consumer Management
 
Consumer Registration
The Design/Change-Time Policy Used for Consumer Registration
Design-Time Consumer Registration Scenario
Run-Time Consumer Registration Scenarios
Viewing Consumer Registration Requests
Monitoring Consumer Count of an Asset
Modifying Consumer Details
Unregistering Existing Consumer
Synchronization of Gateway Application from API Gateway to CentraSite
Synchronizing Consumer Applications through CentraSite Business UI
Synchronizing Consumer Applications through CentraSite Control
Managing Consumers through Command Line Interface
In CentraSite there are three categories of consumers:
*Registered Consumers: Refers to the developers who can register to consume the assets available in the catalog. You can provide registered consumers access to asset's metadata or develop processes that notify them when modifications are made.
*Arbitrary Asset Consumers: Refers to any arbitrary asset that consumes any other asset in the CentraSite registry for the design-time usage.
*Consumer Application Consumers: Refers to the consumer application that consumes (invokes) virtual services at run-time. These consumers are represented in the CentraSite registry by instances of the Application asset which are used by Mediator to determine from which computer application a request for a virtual service originated.
The ability of Mediator to relate a message to a specific consumer application enables Mediator to:
*Indicate the consumer application to which a logged transaction event belongs.
*Monitor a virtual service for violations of a service-level agreement (SLA) for a specified consumer application.
*Control access to a virtual service at run-time (that is, allow only authorized consumer applications to invoke a virtual service).
Definition of Application Assets in CentraSite
The Application asset type is one of the predefined asset types installed with CentraSite. Application assets are used by the policy-enforcement point (PEP) to determine from which consumer application a request for an asset originated. An Application asset defines the precise characteristics by which the PEP can identify or authenticate messages from a specific consumer application at run-time. An application asset has the following attributes for specifying these identifiers:
*IPv4 Address: specifies one or more 4-byte IPv4 addresses that identify requests from a particular consumer application. (This attribute is queried when the Identify Consumer action is configured to identify consumer applications by IP address.)
Example: 192.168.0.10
*IPv6 Address: specifies one or more 128-bit IPv6 addresses that identify requests from a particular consumer application. See the IPv6 addressing architecture specification for details of this format.
Example: 1234:5678:9ABC:DEF0:1234:5678:9ABC:DEF0
*Identification Token: specifies the host names, user names, or other distinguishing strings that identify requests from a particular consumer application. (This attribute is queried when the Identify Consumer action is configured to identify consumer applications by host name, HTTP user name, WSS user name, or a custom token.)
*Consumer Certificate: specifies the X.509 certificates that identify requests from a particular consumer. (This attribute is queried when the Identify Consumer action is configured to identify consumer applications by a consumer certificate.)
Identification of Consumer Applications at Run-Time
To determine the consumer application from which a request was submitted, a virtual service must have a run-time policy that includes an Evaluate * action. This action extracts a specified identifier from an incoming request and locates the Application asset defined by that identifier.
For example, if you configure the Evaluate IP Address action to identify consumers by IP address, Mediator extracts the IP address from a request's HTTP header and searches its list of Application assets for the application that is defined by that IP address.
You can configure the following Evaluate * actions to identify consumer applications based on the following information in a request message:
Identifier
Description
IP Address
The IP address from which the request originated.
Host Name
The name of the host machine from which the request originated.
HTTP Authentication Token
The user ID submitted by the requestor when it was asked to provide basic HTTP credentials (user name and password).
WS-Security Authentication Token
The WSS username token supplied in the header of the SOAP request that the consumer application submitted to the virtual service.
Consumer Certificate
The X.509 certificate supplied in the header of the SOAP request that the consumer application submitted to the virtual service.
XPath Expression
The custom token supplied using an XPath expression in the header of the request that the consumer application submitted to the virtual service.
OAuth2 Authentication Token
The OAuth2 credentials supplied in the header of the SOAP request that the consumer application submitted to the virtual service.
Kerberos Authentication Token
The Kerberos token supplied in the header of the SOAP request that the consumer application submitted to the virtual service.
When deciding which type of identifier has to be used to identify a consumer application at run-time, consider the following points:
*Identifiers that represent user names are often not suitable because the identified users might submit requests from multiple consumer applications.
*Although identifying applications by IP address or host name is often a suitable choice, 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 message itself (using an XPATH expression), is often the most trouble-free way to identify a consumer application.
Registration of Application assets as Consumers of Virtual Service
You use the Consume action in CentraSite Business UI to register an Application asset as consumer of a virtual service. This action establishes an association between the Application asset and the virtual service that it consumes. Registering an Application asset with a virtual service also enables you to use the Asset Navigator feature in CentraSite Business UI to quickly determine which virtual services a consumer application consumes using the Service Versioning And Consumers usecase.
Additionally, if you use the Authorize User policy action to control access to a virtual service at run-time, only registered consumer applications are allowed to invoke the virtual service. Consequently, when you use this form of access control, the consumer applications that are permitted to use a virtual service must be registered to the virtual service.
You register Application assets as consumers of an asset using the following methods:
*CentraSite Business UI
*CentraSite Control
Synchronization of Application assets in CentraSite with Mediator
Mediator maintains a list of consumer applications specified in CentraSite that are authorized to access the API published to Mediator. When Mediator identifies a consumer application at run-time, it searches the list of Application assets that it maintains. This list is synchronized from the CentraSite registry when you synchronize the consumer applications in CentraSite with Mediator.
There are two different lists of consumers in a policy enforcement point (PEP) such as webMethods Mediator:
*List of Registered Consumers: List of users and consumer applications (represented as Application assets) who are registered as consumers for an API in CentraSite, and available in Mediator.
When you synchronize applications who are already registered as consumers for an API to Mediator, these synchronized applications are maintained as a list of registered consumers in Mediator.
*List of Global Consumers : List of all users and consumer applications (represented as consumers) available in Mediator.
When you synchronize applications who are not yet registered as consumers for an API to Mediator, these synchronized applications are maintained as a list of global consumers in Mediator.
You synchronize consumer applications in CentraSite with Mediator using the following methods:
*CentraSite Business UI
*CentraSite Control
*CentraSite Command Line Tool