Consumer Identification plays a key role in the Service Intermediary where consumers of a service can be identified based on a certain criteria. Consumers can be individuals as well as an organization and also could be an application.
Motivation:
1) Consumers need to be authenticated; WS-Security based operations need to be enforced and privileged access needs to be provided at runtime.
2) Existing industry standard based entities could be used to identify a consumer such as IP,IP-Range, WS-Sec Token, HTTP Auth token, X509 Certificate, SAML tokens
3) Enforcement Points can make use of the ID to enforce consumer specific policies. Such as SLA, Deprecation, WS Security
4) Existing directory stores can be used to get user/org/group specific information for access control depending on runtime authentication using the consumer Identity.
5) Tracing service usage based on consumers
6) Using alias credentials for ID transformation.
Target usage:
Mostly B2B, C2B
WS Intermediary/proxy usage:
High
Domain:
Network based applications
Participants/Actors:
Consumers, Applications
Consequences
Downsides: needs configuration; if the traffic manager/Box goes down then no service would be accessible.
Dependency:
This capability will depend on the creating of a consumer application with or without users.

Motivation Scenario 1
For authenticating a consumer of a services one needs to have a handle to some form of IDs by which these consumers could be authenticated against a store/repository.
Keeping with the one way request only or two way request/response paradigms the point and mode by which a requester could be identified is either using transport specific details or to be more precise using information contained in the request itself.

Motivation Scenario 2

Currently, from an industry acceptance perspective the following are the ways by which user/consumer credentials are sent across with the message.
a) Context based or transport header based, here the way context information could be used is as follows
i. IP based: in IP based identification a consumer will be identified by the IP in case of a Servlet based request (JMS or other protocols may not make this available). An IP based identification again would have certain restrictions in case the user needs to login from a different machine or location where the IP is different it would fail to identify the user/consumer
ii. IP range: In this an IP range is provided such as 192.168.0.1 to 192.168.0.255 this would also allow users to be identified as coming from a group.
iii. HTTP Auth token, in case http transport mechanism is used then the auth token could be used for identifying the consumer.
b) Content based where the user information is embedded in the request itself.
i. Say for instance using WS-Security the SOAP header would have the WS-Sec token element which will have the credentials of the consumer.
ii. X509 Certificate based authentication: here the certificates content could be used to identify the consumer.
iii. SAML token could be extracted and then could be validated against a provider. In this scenario a SSO feature could also be introduced.

Motivation Scenario 3

When we talk about a policy what we mean is that it has certain terms associated with it and these terms are nothing but assertions which would be validated at runtime. So from a general perspective a policy could have a number of assertions and each assertion would result in a pass or a failure depending on a context. Let’s understand the concept of a policy with some examples.

Policy 1
Say for instance a service provider organization and a consumer application have an agreement by which the PO agrees to certain terms such as being SLA, Security, and Routing. Let’s drill down into the various terms:
SLA
The service level agreement dictates that the PO will provide a service uptime of 90%, responses will be served within 1ms.
Security
The PO agrees to decrypt all messages from a consumer application

Routing
The PO agrees to do a performance based routing where the best possible server in terms of response time needs to be used.

Policy 2
In this case the PO agrees to the following
SLA
PO will provide a service uptime of 60% and a response time which is within 50 ms
Security
All messages will be encrypted and sent by the consumer and the PO will decrypt them as well as encrypt the response.

Understanding the policies and conclusion

What we see here is that for every consumer identified the policy assertions and the evaluation criteria could be very different. In such a case one would need to define consumer centric policies, of course there will be scenarios where some assertions could be global in nature and could be applied across consumers.
A generic policy framework would certainly add value in terms of making the policy more consumer as well as business centric.

Detailed policy framework would be available as a separate document.

Motivation scenario 4, 5

Consumer identification could also play a major role in reporting where consumer applications as well as provider organization could track the usage of a service in terms of the actual requester. Further this could also play a significant role in understanding how a particular service reacts for various consumers, such as one can track that requests coming from a specific consumer failed the maximum number of times where as other consumers never had any issues. The possible outcome could be that the users failed to provide enough information required for processing a request, say the security assertion dictates that the message should not be encrypted but the consumer sent encrypted messages.
The other eye opener is that the notion of an agreement between a provider and a consumer should be made available to a consumer so that consumers can send requests which confirms to the agreement and this again is another motivating factor to have policies which are consumer centric.

Motivation Scenario 6

There could be situations where native services/ endpoint services could have a security mechanism by which access is allowed to a service. Suppose this service is provisioned in an intermediary and doesn’t have any security terms associated with the policy, credentials for the native service needs to be added to the request otherwise the service will fail from the native service provider.

In case such a case the consumer identity could be directly used or could fetch credentials required by the native service from local/remote store and add the credential to the request (in case of SOAP add it as Ws Sec token if that’s what is mandated by the native service)

Soumadeep Gourangi

A key entity in realizing SOA Governance is the Service Intermediary. To understand the importance of its existence, real world scenarios could help in identifying the required capabilities in dealing with Web services/assets. This is required as the service assets can be easily managed across service providers and consuming applications.
Motivation:
1) Service providers would like to dictate service access privileges for Consumers.
2) Make the service assets manageable by providing viewer ship – A taxonomy-based approach could be used for categorization.
3) Changes in service definition needs to be propagated / notified to targeted consumers; changes more specific to service life cycle - Available, Unavailable, Deprecated, Versioned, Suspended (could be merged with unavailable). Also in case of versioning.
4) Design time policies, specific to a consumer/Organization required to enforce assertions during creation
5) Privileges need to be defined for the possible function/operation availabile for a service
6) Roles for a set of privileges
7) Groups having a set of roles
A complete distinction needs to be made between the users of the system.
9) Personalization needs to be done on consumers where new services, which are added to the system, can be showcased to the existing consumer base for them to subscribe.
10) An easy subscription mechanism is required which consumers can subscribe to based on related service interest. When new services are added the consumers can have a glimpse of the new service. If they wish to use the service they can send in a request to the service provider. Involves a subscription life cycle.
11) While defining runtime policies the provisioned services need to be used directly for similar services in policy assertion such as Routing, SLA etc –also filtering of services.
12) When adding a service to the system one would require a WS-I basic profile 1.0 compliance test for the service
Target usage:
Mostly B2B, C2B
WS Intermediary/proxy usage:
High
Domain:
Network based applications
Participants/Actors:
Consumers, Service providers, Applications
Dependency:
Depends on user, role, group, organization, service, WS-Security

Motivation scenario 1 & 2:
At design time a service provider admin can add a service to the system and assign privileges to consumers. A service WSDL URL could be used by the service Provider that is added to a category or taxonomy. Say, Stock Service; under the category of finance. (Note: One could use a UDDI specified taxonomy, for this instance let’s consider a custom taxonomy or a folder/item analogy where folder is the group/domain and item is the service itself).
A service provider would also assign viewer-ship privilege to 0 or more consumers for a particular service.

Viewer-ship
A Consumer application/user could visit our published service page and navigate the folder structure and view the services that are available to them. This again would depend on the kind of privilege the user has. Mostly for consumer application/users it will be view services.

The other purpose of this is to have a clear distinction between the various users of the application as a whole.

Motivation Scenario 3:
Changes to the state and accessibility of a service need to be tightly monitored and the information needs to be made available to a consuming application. The mode by which this would be achieved is more of an implementation matter and could be configuration based. SMTP or SNMP based mechanism could a way by which this could be accomplished. The purpose would be to let the consuming application know the state. In case of change of version in which say the method signature has changed it should be notified so that the consuming application can take preemptive action.

Motivation scenario 5,6,7 and 8
Service Privileges: an imported service (WSDL) can be privileged based on CRUD (Create Read/view, Update and delete) operations, where the Provider Organization Administrator (POA) can give selective privileges to other Provider Organization Users as well as service consuming organizations.

Service Provider Roles: Roles will be critical to the provisioning of services. The main category of roles that would be useful from a provisioning perspective for a Service provider is:
1) POA – Provider Organization Administrator: responsibility of this role is to assign privileges/roles to various other users of the Service Provider Organization and also create users.
2) SI – System Integrator: This role will provide Service access to consumer applications (Note: Consumer applications are users of services, each consumer application can have users associated with them)
3) CA – Consumer Applications: This role will be given to consumers of a particular service consuming organization for a particular Service Provider Organization, in most cases they can view the services.
4) Other roles could be added by the provider organization to suit their purposes.

In a nutshell, there will be two kinds of organizations that would participate in the service life cycle. The Provider Organization and the Consuming Organization. Each of them can have users and participate during the different phases of the service life cycle. The first phase of provisioning would be more focused towards adding an end point (WSDL in most cases) to the system and assigning it to a category. In the second phase these endpoints would be made available to the SI for selectively exposing them to consumers for consumption.

Defining consumer applications/users would be more evident when we introduce Security features. Say for instance we provide a WS-Security capability and allow the client to send encrypted data to our proxy based intermediary. Now to decrypt the data we would require a public key. At the intermediary end the only way to find the public key would be by using the Consumer Application ID to fetch it from the keystore.

Motivation scenario 9,10:
Personalization of services could help consumers to easily access related services or the services that the consumers are interested in. The mechanism by which this can be achieved is to capture service interest area from consumers in terms of service categories. So when a new service is added to the system this could be linked to interested consumer and showcase the new services. When the consumer application/user logs in to the system these new services could be shown to them. If interested then the Consumer Application users can send a subscription request and avail the service. This would certainly have a workflow associated with it – in terms of who will assign service permission, what would be the terms under which this service will be made available etc.

Motivation scenario 12

WS-I Basic Profile test would be an important criteria by which a service being added could be tested for conformance. This would serve two purposes 1) Validate the usability of the service and 2) also serve as an item on the consumer’s checklist as this has wide acceptance.

Soumadeep Gourangi

With Business Activity Monitoring being slowly accepted by the enterprises as the key to realizing tagible business benefits, we at Bizsensors are proud to present Gourangi a BAM product which aims at bridging the business and technology gap.

Soumadeep Gourangi BAM, Bizsensors, KPI, Product