Document Actions
6.1.2.1.
Introduction
Up one level
Client side
The most important thing to know about using the GRIA OGSA-DAI Service with the OGSA-DAI API is that the endpoint to use is different to the GRIA service endpoint. For the OGSA-DAI API you must use the "OgsaDaiSubscription" endpoint (e.g. https://your.machine/gria-ogsadai-service/services/OgsaDaiSubscription).
The GRIA API is used to perform management actions (e.g. resource creation, deletion and access control) on the OgsaDaiServiceI2, OgsaDaiResource, OgsaDaiRole and OgsaDaiSubscription endpoints. The resource that represents a client's login to a specific data resource is the OgsaDaiSubscription. Therefore it is this endpoint that is the only one dealt with by the OGSA-DAI API.
The SOAP messages that are generated by the OGSA-DAI client-side library require slight modifications to become compatible with the GRIA OGSA-DAI service. These modifications are:
- Removing the Data Resource ID from the URL so that all calls go to a single remote service (the OgsaDaiSubscription endpoint rather than e.g. OgsaDaiSubscription/DAIxxx-xxx-xxxx-xxx).
- Adding the Data Resource ID as a WS-Addressing SOAP header inside the message.
- Signing the request with the user's certificate, and verifying the signature of the response from the service.
- Including user authentication information to ensure that other users cannot access any OGSA-DAI sessions you create.
- Adding tokens to assert group membership.
These modifications are performed by an AXIS message handler chain - a collection of Java classes that can change the SOAP message at various stages during its processing. More information about message handlers is available in the Axis documentation.
Service side
On the service side, any OGSA-DAI API invocations first travels through the GRIA infrastructure, checking the integrity of the message and the security constraints on the database resource subscription in use. The message is then passed on to an embedded OGSA-DAI service which operates in the usual way.
An activity running on OGSA-DAI may use the RoleMapper system to map from a user's credentials to a database login. In a GRIA OGSA-DAI installation this is all configured through the web administration interface - mapping data resource roles onto database logins. Before the embedded OGSA-DAI service is invoked, the GRIA part sets the client's credentials to be the data resource subscription ID. A custom role mapper implementation (supplied) then takes the subscription ID, finds the parent resource (a data resource role) and gets the database login information from there. All this work is transparent to an activity so existing activities using a role mapper can be used unmodified.
