Notes towards a Security Architecture

As a project, we have experienced some difficulty in arriving at a security architecture, still less any implementation. This is partly because, untill recently, we have had no team member with an interest in, knowledge of and responsibility for the subject. This has now changed, but I believe there is still a problem in making progress. I suspect most of us (self included) are still somewhat confused over available technologies, our requirements, and how to use the former to meet the latter.

The Manchester team discussed security at a local meeting on 14 Dec 2004. This topic attempts to capture the discussion in the hope of bridging the gap between the security experts and those developing the functional components of myGrid.

Abstracting the myGrid architecture

The current (Dec 2004) DeploymentArchitecture illustrates the actual relationship between myGrid components, but excludes third-party services invoked through workflows, for example.

This diagram tries to abstract some security properties:

Some user u accesses myGrid via a client application, and in particular Taverna and its plugins or in future the portal. The user, directly or indirectly, supplies the client with some credentials by which the client recognizes the user's identity. Credentials might be a username/password combination, or a digital signature and public key certificate.

The user's identity needs to be associated with the user's representation as a Person in the MIR, so that they can gain access to entities such as studies tied to that Person, and to support provenance gathering.

The client preserves the user's identity as part of its context (in the portal case, the portal will need to support multiple sessions each their own context). The client will invoke other myGrid services, directly or via a workflow enactor that might be configured as a separate service. The client will need to pass some user credentials to the enactor, which will also maintain the user as part of its context, and both will pass the user's credentials to other myGrid services.

Some myGrid services will control other resources (such as databases) that support their own notion of user identity/credentials: for example, MySQL^? uses its own username/password support to control access. Such services will need to map the user's myGrid identity u to the correct resource identity u' and pass credentials for u' to the resource. Note that the MIR itself is such a service. There are two interesting extremes to the u_-_u' mapping:

• Each u maps to a distinct u': this might allow us to exploit smart RBAC support in a DBMS such as Oracle but could pose difficulties when other services are deployed on other resources (or none)
• Each u maps to the same u': effectively, u' is the resource UID for the service and myGrid access control is completely separate from DBMS access control. This is the approach currently taken

We also have the case of third-party services that have their own security requirements: some myGrid component (the enactor, or Feta for an underlying registry) would have to map between the myGrid user identity and the relevant service credentials.

Overall security requirements

We want to determine each attempted user's identity to:

1. grant or deny access to each myGrid service as a whole
2. for permitted users, determine the actions they may perform on each resource managed by the service
3. to relate the human user to their representation as a Person in the MIR
4. when users invoke services or modify resources, to associate provenance metadata for the action with the relevant Person

(1) above may be supported entirely in middleware (e.g. the service's container - Tomcat in our case) To support other requirements, we will have to add logic to the relevant services.

-- NickSharman - 14 Dec 2004