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
Deploying Consumer Applications Through CentraSite Control
Managing Consumers through Command Line Interface
A consumer application is represented in CentraSite by an Application asset. An Application asset is an instance of the Application asset type, which is one of the predefined types installed with CentraSite. An Application asset defines the precise characteristics by which webMethods Mediator can identify messages from a specific consumer application at run time.
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).
The following figure shows the log entry for a request that a consumer application has submitted to a virtual service. Note that the entry identifies the consumer application from which the request originated. This identification is enabled by an application asset that has been defined in the CentraSite registry.
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 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.
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 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.
Application Assets in CentraSite
An application asset specifies identifiers by which messages from a particular consumer application are recognized 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.)
For example, the following application asset describes a consumer application called SalesAnalyzer, which is defined by a range of IP addresses:
Synchronization of Application Assets in CentraSite with Mediator
When Mediator identifies a consumer application at run time, it searches a local list of application assets that it maintains. This list is downloaded from the CentraSite registry when you synchronize the consumer applications in CentraSite with Mediator.
You can synchronize Application assets with Mediator using the CentraSite Command Line Interface.
Identification of Consumer Application
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 Asset with a Virtual Service
Use the Consume action in CentraSite Business UI to associate an application asset with a virtual service. This action establishes an association between the application asset (which represents a consumer application) 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.
Considerations while Defining Applications
When defining application assets, keep the following points in mind:
*Any user who has permission to publish an asset to CentraSite can define an application asset. However, not all users are generally qualified to create an asset of this type. Defining applications is a critical task that should be performed only by an administrator who is familiar with the Mediator(s), virtual services, and run-time policies in your environment.
*An application asset becomes available to Mediator only when you synchronize the consumer application in CentraSite with the Mediator.
*Treat application assets as global objects and make them available to all organizations. Be sure that your registry contains only one application asset per consumer application (that is, a consumer application should be represented by one and only one application asset in the registry).
*Be sure that the identifiers that you assign to an application asset are unique to that application asset. If multiple application assets have the same identifier, Mediator associates the identifier with the first matching application it finds in its local list of application assets at run time.
*If you control access to virtual services based on consumer applications (that is, you use run-time policies that include the Authorize User action), consider:
*Including an approval step in your consumer-registration policy that requires a security administrator to review and approve the registration event.
*Giving only a small group of knowledgeable administrators permission to modify an application asset after it is registered to a virtual service. This prevents users from adding unauthorized identifiers to an existing application asset and thus, allowing unauthorized consumer applications to access the virtual service.
Copyright © 2015- 2017 Software AG, Darmstadt, Germany. (Innovation Release)
Product LogoContact Support   |   Community   |   Feedback