In CentraSite there are two concepts of "consumers".
The first refers to developers who discover assets in the catalog that they want to reuse. Such developers can register to become registered consumers of those assets. You might give registered consumers access to more of the asset's metadata (i.e., enable them to view additional profiles) and/or develop processes that notify them when changes occur to an asset that they consume.
The second concept refers specifically to a computer application that consumes (invokes) virtual services at run time. This specific type of consumer is represented in the registry by instances of the Application asset type. Application assets are used by webMethods Mediator to determine from which computer application a request for a virtual service originated.
This section discusses the type of consumer that represents a computer application that consumes virtual services. For clarity, the following sections in this document refer to this type of consumer as a consumer application.
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 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 (i.e., 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.
To determine the consumer application from which a request was submitted, a virtual service must have a run-time policy that includes the Identify Consumer 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 Identify Consumer 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 Identify Consumer action 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. |
An application asset specifies the precise identifiers by which messages from a particular consumer application will be recognized at run time. An application asset has the following attributes for specifying these identifiers:
IPv4 Address, which 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, which specifies one or more 128-bit IPv6 addresses that identify requests from a particular consumer application. See the IPv6 addressing architecture specification http://tools.ietf.org/html/rfc4291 for details of this format.
Example: 1234:5678:9ABC:DEF0:1234:5678:9ABC:DEF0
Identification Token, which 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, which 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.
When Mediator identifies a consumer application at run time, it searches a local list of application assets that it maintains. This list is initially downloaded from the CentraSite registry when you start Mediator. Mediator periodically resyncs the list to keep it up-to-date.
Be aware that application assets are made available to Mediator as soon as they are added to the registry. That is, an application asset that you add to CentraSite is given to Mediator the next time Mediator resyncs its local list with the registry. Therefore, you should not add an application asset to CentraSite's registry until you are able to provide the proper identifiers for it.
When deciding which type of identifier to use to identify a consumer application at run time, 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 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.
Note:
Depending on which form of identification you choose, the run-time
policy that you use to extract the consumer identifier might need to perform
certain prerequisite actions prior to the Identify Consumer action. For
example, if you want to identify a consumer application by WS-Security
authentication token, your run-time policy must execute the Require WSS
Username Token action before it executes the Identify Consumer action.
These dependencies are described in the user documentation for the Identify
Consumer action.
You use the Register as Consumer command in CentraSite to associate an application asset with a virtual service. This command 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 enables you to use the Impact Analysis feature in CentraSite to quickly determine which virtual services a consumer application consumes (and also determine which consumer applications use a particular virtual service).
Additionally, if you use the Authorize Against Registered Consumers 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.
When you execute the Register as Consumer command, CentraSite does not immediately register the application asset with the virtual service. Instead, it triggers a review and approval process that includes the following steps:
CentraSite submits the request to the owner of the virtual service for review and approval.
The virtual service owner reviews the request and approves the request or rejects it. If the request is approved, CentraSite executes the consumer-registration policy. This policy actually registers the application asset with the virtual service.
The consumer-registration policy is a policy that includes the Register Consumer action and executes on the OnConsumerRegistration event. The OnConsumerRegistration event occurs when the owner of the asset approves the registration request, not when the user submits the registration request. CentraSite does not provide a consumer-registration policy out-of-the-box. You must create this policy for your instance of CentraSite. CentraSite will not enable the consumer-registration feature until you create this policy.
Important:
If you will be using the Authorize Against Registered Consumers
policy action to control access to a virtual service at run time, you should
strongly consider including an approval step in your consumer-registration
policy. When you use this form of access control on a virtual service,
registering a consumer application with the virtual service grants that
consumer application permission to invoke the service. To ensure that only
authorized applications are registered with a virtual service, you might want
to have a security administrator review and approve this type of registration
request.
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 webMethods Mediator(s), virtual services and run-time policies in your environment.
An application asset becomes available to Mediator as soon as you add it to the registry. Do not add an application asset to CentraSite until you are able to provide the exact identifiers for the consumer application that it represents.
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 (i.e., 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 will simply associate 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 (i.e., you use run-time policies that include the Authorize Against Registered Consumers 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 will prevent users from adding unauthorized identifiers to an existing application asset, and thus, allowing unauthorized consumer applications to access the virtual service.
