Operations in the DEWS System

This page describes all the high-level operations in the DEWS system from the point of view of the servers. It describes each operation that each server provides in terms of:

• The purpose of the operation
• The client system(s) performing the operation
• The transport used (HTTP/HTTPS Web Service or local API)
• The contents of the incoming message (does it use SOAP?) and whether or not it is signed/encrypted
• The contents of the outgoing message and whether or not it is signed/encrypted

This document was written during the DEWSTechnicalWorkshop6Feb07. Please refer to the system architecture diagram on DEWSTechnicalWorkshop6Feb07Notes.

Summary notes

Nothing uses message-level encryption. We use transport-level encryption (HTTPS) for interactions with the health attribute authority and gatekeeper because this is required by the deployment environment at the Met Office. Messages that are sent to servers are generally SOAP messages that are signed by the client that is sending the message. Where a message is signed, the signing certificate must be included in the SOAP header. Replies from servers are not signed.

Portal Attribute Authority

getAttCert(user)

Purpose

Returns an original attribute certificate for a portal user. The portal user has already been authenticated by the portal.

Client system

The portal server.

Transport used

HTTP Web Service. Cannot be a local API call even though they are co-located because the AA is implemented in Python and the portal is Java. AA is behind a firewall so cannot be accessed outside Lost Wax. (Could also re-implement AA in Java or Jython and make into an API call if there were time.)

Incoming message

SOAP message containing user id, signed by the Portal.

Outgoing message

The attribute certificate (XML doc) signed by the portal att authority in a SOAP wrapper, or a SOAP fault, or access denied message.

Marine Attribute Authority

getAttCert(user)

Purpose

Returns an original attribute certificate for the BMT SEAInfo system.

Client system

BMT SEAInfo

Transport used

HTTP Web Service. No need to hide the attribute certificate on the wire.

Incoming message

Very simple SOAP message signed by SEAInfo, possibly containing username="seainfo". OR BMT could inject an arbitrary username into the message provided that the message is signed by SEAInfo.

Outgoing message

The attribute certificate (XML doc) signed by the marine att authority in a SOAP wrapper, or a SOAP fault, or access denied message.

getAttCert(portalAttCert)

Purpose

Maps a DEWS Portal attribute certificate to produce an att cert recognised by the marine Gatekeeper

Client system

DEWS Portal

Transport used

HTTP Web Service.

Incoming message

SOAP message containing portal att cert, signed by portal server (recall that the att cert is signed by the portal att authority)

Outgoing message

The mapped attribute certificate, signed by the marine att authority in a SOAP wrapper, or a SOAP fault, or access denied message.

Health Attribute Authority

getAttCert(portalAttCert)

Purpose

Maps a DEWS Portal attribute certificate to produce an att cert recognised by the health Gatekeeper

Client system

DEWS Portal

Transport used

HTTPS Web Service (required by deployment environment)

Incoming message

SOAP message containing portal att cert, signed by portal server (recall that the att cert is signed by the portal att authority)

Outgoing message

The mapped attribute certificate, signed by the health att authority in a SOAP wrapper, or a SOAP fault, or access denied message.

Gatekeeper

The Gatekeepers are designed to be as dumb as possible, in that they are only concerned with security credentials and do not have to understand the "payload" of the message (i.e. the requests to the underlying data services). This means that the Gatekeepers for the health and marine streams can be identical in terms of their code.

processMessage(message)

Purpose

Check security credentials (att cert) of incoming message and if valid forward the payload to underlying data server.

Client system

DEWS Portal or BMT SEAInfo

Transport used

HTTPS Web service without client-side certificates (on health side), plain HTTP on marine side.

Incoming message

SOAP message containing data request (XML doc or URL) and attribute certificate, signed by the client.

Outgoing message

The response from the underlying data service or "access denied" or SOAP fault (denoting system error).

IMPORTANT The Gatekeeper must be able to make a decision on whether the request is allowable for the given user. In order to preserve the "dumbness" of the Gatekeeper, we must make sure that the Gatekeeper does not have to understand the request (this would duplicate request-parsing code in Geoserver). Therefore the data servers need an extra operation, String[] roles = getRolesRequiredFor(request), which returns the list of roles that are required to perform the given request. The Gatekeeper will then check to see if one of these roles is present in the attribute certificate.

This has the slight disadvantage that the data server will have to parse the request twice, once to get the required roles and once to actually perform the request. Also, we need to implement a new Web Service (or at least a new operation) that performs getRolesRequiredFor(). However, the key advantages are that the Gatekeeper code can be identical on both the marine and health sides and we don't repeat request-parsing code between Geoserver and the Gatekeeper.

The marine gatekeeper will also use getRolesRequiredFor() for checking that users are entitled to see the status of an ongoing asynchronous request (or ultimately to get the data).

For marine metadata (which is not secured), the getRolesRequiredFor() will return "all" or something similar, which tells the Gatekeeper to ignore the incoming attribute (if there is one). In this case, we should really use an interface to the Gatekeeper that does not check client certificates. However, this is difficult with the current Websphere, which will check signatures from all operations in a given Web Service. We could create a separate Gatekeeper for unsecured operations that doesn't check signatures, but perhaps we should only do this if we have time.

This is an illustration of a (synchronous) data request through the Gatekeeper. Note that the Gatekeeper never has to parse the data request itself, but Geoserver has to process the data request twice (not expected to be a significant source of inefficiency).

Notes on this diagram:

• When the message arrives at the Gatekeeper, Websphere will check that the SOAP message is correctly signed: the signing certificate must be present in the SOAP header. The certificate of the CA that signed that certificate must be present in the Gatekeeper's keystore. Many CA certs can be present in Websphere's keystore, so BMT's SEAInfo cert and the DEWS portal cert could be signed by different CAs.
  • The signing certificate must be included in each signed SOAP message because Websphere will not allow us to check the message signature against more than one stored certificate (SEAInfo and portal) and it would be unacceptable to give SEAInfo and the portal the same private key!
• The checkAttCert() method of the Gatekeeper checks two things:
  1. The holderDN in the attribute certificate matches the signer of the SOAP message (which will be BMT SEAInfo or the portal server)
  2. The attribute certificate is signed by the relevant attribute authority (health or marine)

-- JonBlower - 07 Feb 2007