Notes from the GGF15 OGSA Data WG session on Data and Security.

Authentication use case:
A portal manages authentication via usernames/passwords. The portal then submits jobs to a Grid using an X.509 certificate.  The Grid trusts the portal managers to properly authenticate its users.  As a particular (implemented) sub-case, that trust may exist because portal users can only submit a limited range of pre-identifed jobs to the Grid, rather than arbitrary executables.  The Grid may also associate a lower-level of authentication with portal users (supported by SAML 2.0?).

Shibboleth may well be relevant to this use case.

Authorisation use case:
A user may only be authorised to access certain data if (i) they are performing a certain role at the time and (ii) they are in a particular place.  Clause (i) requires dynamic role management.  Clause (ii) requires the ability to track where a request originated, or at least where a user authenticated themselves.  This in turn requires a transport mechanism for passing extensible attributes and a callback mechanism for requesting them.  (As a performance optimisation, the system could dynamically adapt to automatically pass the attributes that it expects to be required).  Attributes may be requested from more than one place (e.g. a record of users and a record of logins).  Shibboleth does not currently support this.

Auditing is an essential part of security.  We may need to extend the RUS/UR specs to handle our requirements.

Data may be restricted in where it may be sent, who may read it, and possibly other constraints (I don't think I caught all the ones that were mentioned).  This is not the same as saying that data resources may be so restricted. The policy needs to be associated with the data as it is transferred from site to site.  It is possible that WS-Security + XAMCL provides the necessary support.

In general, a system may/will require trusted intermediaries to perform authentication, auditing, etc.

The architecture may have to say where decision points must or should be provided.  Most people think of decision points where operations are called, but they may also be recommended before transferring the results of an operation to a third-party, for example.

A client may need to specify the encryption requirements for ongoing data messages following a query or other operation. 

The security area groups would welcome use cases.   We should work with the LS-RG to see if their use cases cover our concerns.