Role(s):                                  Service Customer, Service Provider

Component(s):                     Gateway (GW)

Service Instance Registry (SIR)

Security Token Service (STS)

License: MS-PL

The gateway toolkit supports dynamic and extensible message policy enforcement - this ranges from routing (virtualisation & encapsulation) over authorisation and access restriction (in combination with e.g. the STS) to message transformation (interoperability). This toolkit enhances the messaging channels of (web service) based transactions, allowing to enforce any amount of policies upon in- and outcoming messages.

Usage Instructions

Installation Requirements

Deployment Tips

Message Infrastructure API

Usage Instructions

An essential functionality of the gateway consists in message routing - actually it depends on the usage scenario whether this functionality is considered required. As we foresee the main use for the gateway consisting in virtualisation & encapsulation of resources / services, routing is required as an integral part of this capability, the Service Instance Registry maintains routing endpoints and their exposed virtual address, so that any message going over the gateway will be redirected from the virtual address to its accordingly stored endpoint in the SIR. This allows the calling application to maintain a static endpoint which is resolved in the SIR using information provided by an administrator or by exploiting additional context information contained in the message header.

Note: The Gateway can be used without the SIR, in which case the user will have to write their own policy handlers.

The gateway can be extended by a security policy handler - in particular the Security Token Service (STS) by EMIC. The STS is a specific policy handler to ensure secure and authenticated message exchange between (trusted) parties. To do this, the STS requires that dedicated collaboration tokens have been created and registered. Therefore, the security token service is responsible for three topics.

·        Token issuance: First it issues tokens that can be used to protect outgoing messages, to authenticate the sender and to convey authorization information about the sender to the receiver's side.

·        Policy store: Second, the STS is the place where the security policy resides. The security policy is kind of the 'rule set' for token issuing and validation of tokens, and for access control decisions. When issuing a token, the STS checks embedded claims about the requestor in the token. Token issuance can be parameterized by the requesting application, e.g. by giving an identifier of the sending application, or by requesting particular types of claims.

·        Token validation and access control decision: Third, the STS checks incoming security tokens and performs access control. Thus, it acts as a policy decision point (PDP). The STS of the receiving side will not accept any token, but only tokens that are expected. So this again makes the STS to the place where the policy resides, this time on the receiver's side. The configuration of the receiving STS determines who may access the service protected by this particular STS and what criteria have to be fulfilled to grant access to the service. The criteria are expressed by signed tokens and the configuration of the STS what sender-side STS may issue what kind of token.

Any invocation of a consuming application via the gateway will be enhanced with the credentials of the sender according to the collaboration details by resolving the destination EPR. Incoming messages on the provider side will be validated against the known collaboration tokens and its response will again be enhanced with the according details from his / her side.

Note: The STS requires the Gateway and the SIR to function properly.

The typical deployment will have at least the Gateway and the Service Instance Registry hosted on a web server which forms the entrance to the resource infrastructure. In order to be able to receive messages, it requires an open port in the firewall on the web server - however, the firewall of the individual service hosts need only be opened for communication with this server, not with the external internet.

Any policy handler extending the gateway could be located on any machine that the web server can access - potentially even located in the internet. Since messaging between gateway and policy handler is not secured, this is only recommended for non-critical requests though.

Installation Requirements

· Windows Server 2003 / XP or higher

·.NET Framework 3.5 or higher

· Geneva Identity Framework CTP2

Deployment Tips

Through using "double-blind virtualisation" mechanisms, i.e. by deploying the gateway on both consumer and service provider side, it is possible to alter resources and providers without affecting the calling applications. Next Figure presents a sample deployment of the Gateway infrastructure. The dashed line denotes an indirect link (as the gateway extends the message channel).

· The Gateway is always necessary.

· The Service Instance Registry is highly recommended, but not required

· Policy Handlers (including the Service Instance Registry) can be deployed on separate machines - however, since the communication between Gateway and Policy Handler are not secured, this is only recommended within protected environments

Software Installation

Unload and Unzip the "Messaging Infrastructure Installers.rar" file into the server where you will install the software. Execute BREIN Messaging Infrastructure Setup.exe.

The installer will install the following components:

·         Gateway

·         SIR

·         STS