Notes from DEWS Technical Workshop, 6-7th Feb 2007

System architecture (following simplifications to security system described below)

For a detailed description of all the operations in the system go here.

Notes

Security (Phil Kershaw)

PROBLEM: Websphere 6.1 can't use proxy certs to sign messages because cert and private key must be hard-coded. Might be possible with a feature pack. The feature pack is not yet available and we don't know when it will be so we must assume that it will not be available for DEWS.

Here is Phil's presentation on security (which he didn't get to give...!)

Roles of the components in the security system

Session Manager is optional and contains a Credential Wallet that caches Att Certs, user certs and proxy certs. Attribute Authorities are compulsory to install at a data provider and generate new Att Certs, and/or map Att Certs. Each AA has a cert and private key. The Gatekeeper examines an Att Cert and accepts or rejects a request

First we describe the sequence of events for a "full" installation of security, with proxy certificates. Next we shall describe a simpler security system, which does not use proxy certs (and therefore works around Websphere's limitation) and is also easier to create and deploy.

Sequence of events for getting data via Portal for the first time WITH PROXY CERTS

1. User logs in at DEWS Portal
2. Portal code calls Session Manager with username/password:
   • connect(user, password)
     • proxy_cert, proxy_private_key, user cert = MyProxy.getDelegation(user, password)
     • session = SessionManager.getUserSession(proxy_cert, proxy_pk, user_cert) # session contains a Credential Wallet: a cache of credentials
     • return proxy_cert, proxy_pk, user_cert, session.getCookie()
3. Portal sets cookie in browser
4. Portal gets Attribute Certificate from the Portal Attribute Authority (which goes to the portal user database)
   • portalAttCert = SessionManager.getAttCert(att_auth_address)
     • Attribute Authority implements String[] roles = getRoles(userDN)
       • (roles include gold_user, silver_user etc)
     • Session Manager puts the Att Cert into the Credential Wallet
5. Met Office Gatekeeper (which protects the data) does not understand the portal's roles. We have a trust relationship with the Met Office so we need to map the roles in the portal's att cert to Met Office roles using the Met Office's Attribute Authority
   • mappedAttCert = SM.getAttCert(metOfficeAAAddress, portalAttCert)
     • (Session Manager caches mappedAttCert in Credential Wallet)
6. Portal calls Gatekeeper with mappedAttCert, signing the message with the user's proxy's private key
   • Could sign just a part of the message, but WS-Security tooling makes this difficult. But could use XML-sec instead of WS-Security. This could be another way to get around inability of WS6.1 to sign messages with proxy (i.e. dynamic) certs, but would require extra work.
7. Gatekeeper checks that the user DN in the signature matches the user DN in the Attribute Certificate.

Attribute Certificate is useless if the message in which it sits is not signed by the user's proxy (i.e. the WS-Security signature)

Attribute Certificates are signed by the Attribute Authority that issues them.

Sequence of events with simplified system (no proxy certs)

Credential Wallet will be held in HTTP session on the app server instead of separate Session Manager

1. User logs into portal with user/password
2. Portal checks password against database
3. Portal gets portalAttCert from local Attribute Authority
   • local Web Service call getAttCert(user), message to AA is signed with the portal's private key or use HTTPS with client-side certificate (it's a WS call to bridge Java to Python)
   • portalAttCert is signed by the Attribute Authority's private key
     • The portalAttCert contains the DN of the requestor, which in this case is the portal (not the user)
     • The att cert is modified to contain the ID of the user (TODO)
     • Attribute Authority has an interface to the portal's user database so that it can retrieve roles (i.e. a single database holds usernames, passwords and roles). This interface is TODO.
   • Attribute Cert is cached in the HTTP session, which is acting as the Credential Wallet
     • These certs will vanish when the session is destroyed (logout or timeout)
4. User selects a resource from health or marine data
5. Portal gets mapped att cert from the att auth that is protecting the resource.
6. Portal calls the Gatekeeper with the mapped att cert
   • The Gatekeeper checks that the signer of the request (the portal server) matches the holderDN in the mapped att cert

Potential security risk: if a user can modify his or her server-side HTTP session to inject arbitrary attribute certificates, the Gatekeeper will not be able to distinguish this as unauthorised access because the Att Cert is signed by the portal server, not the specific user. The likelihood of this occurring is thought to be low - we trust the portal application server.

Changes with this simplified model

1. Attribute Certificate needs to change to include username
2. getAttCert() method needs to change to put the username in the returned cert
3. Gatekeeper needs to change to use the username in the att cert for auditing and logging
4. SessionManager (as a separate entity) is removed.
5. No need for a MyProxy server
6. No need for a Certificate Authority
7. Portal needs to implement a CredentialWallet inside the HTTP session
   • Only needs to cache attribute certificates, not user certs or proxy certs

This (almost) harmonises the security approaches in the marine and health streams.

The BMT case in the simplified model

1. BMT SEAInfo has a server certificate
2. Marine Attribute Authority will return an attribute certificate to SEAInfo in response to a request from SEAInfo that is signed by the SEAInfo server certificate.

There is no need for mapped certificates in the BMT case

The Attribute Authorities in the simplified model

The Portal Attribute Authority does no mapping: it returns original att certificates for a given user.

The Health Attribute Authority maps portal att certs to produce att certs that are recognised by the Health Gatekeeper. It does not need to produce original certificates (in the current system)

The Marine Attribute Authority maps portal att certs to produce att certs that are recognised by the Marine Gatekeeper. It also generates original att certs for BMT SEAInfo.

The Attribute Authorities and Gatekeepers are separate entities because it is possible to have an AA without a Gatekeeper (if there were data at the portal for example). However, where both are needed they need to understand the same roles (i.e. they need to be synchronised in this respect).

If someone else wanted to join the DEWS architecture...

Using the simplified model above:

A data provider would implement a Gatekeeper to protect the data and an Attribute Authority to receive att certs and return mapped attribute certificates that are trusted by the Gatekeeper.

A client would implement a means of generating and signing attribute certificates, which will then be turned into mapped att certs by the att authorities that protect the data resources. The client would have to enter into a trust relationship with the data providers.

Workshop achievements

1. Simplified security model agreed upon by all partners
2. Interfaces of Attribute Authorities and Gatekeepers agreed upon
3. Java/Websphere client at Lost Wax successfully interfaced with Python Attribute Authority at BADC.
4. Gatekeeper can now verify the signature of an incoming message, and simple Gatekeeper client created.
5. Verified that it is possible to use different signing certificates.
6. Generated pseudocode for security model and Gatekeeper

Actions

All to be completed by end of Feb.

1. BMT to decide upon their client system (JBoss vs Websphere). Reluctant to use Websphere, but JBoss implementation of WS-Security is not known to interoperate with the Python-based Attribute Authorities (we haven't tried).
2. Brian E to migrate portal from Tomcat to Websphere so that he can use the Attribute Authority client code.
3. Brian E to implement Credential Wallet functionality in portal (the CW will belong to the HTTP session object).
4. Phil to modify attribute authority to produce att certs with a username as an attribute.
5. Phil to eggify AA installation (15 Feb)
6. Phil to install health AA at Met Office (end of Feb)
7. Adit to install AA at ESSC (with Phil's help) (end of Feb)
8. Brian E to deploy Attribute Authority server code (Python) at Lost Wax (with Phil's help) (end of Feb)
9. Adit and Brian to complete Gatekeeper and someone will install at Met Office later.
10. Chris W to implement health data service and give Brian E the call and return interface schema. This will be a RESTful service which returns XML information according to (or close to) Ag's application schema.
11. Still require Java code to verify signature of an attribute certificate (Brian and Adit, Chris Wood has some ideas too). This cert is embedded in the message so we can't just use Websphere to do this.

Outstanding questions

1. Should auditing/logging be centralised or not? One audit/logging WS for all of DEWS or one per stream?
2. BMT client - JBoss or Websphere?
3. What to do about requests for metadata from marine server (unsecured) - a general client might not have a certificate to sign a message with. Also, Websphere won't allow different operations in the same Web Service to have different security profiles. We might have to deploy a separate Web Service on the Gatekeeper to deal with unsecured requests (low priority).

-- JonBlower - 06 Feb 2007