[ogsa-d-wg] Summary of a conversation on security

[Dave Berry]

All,

The following summarises an e-mail conversation I had with some NeSC
staff last month about security and data services.  The questions and
observations were made by several different people.  The summary of the
summary is that there still seem to be open questions in this area.

Dave.


Question 1:
What is the relationship between the native authorisation provided by a
data resource and the authorisation provided by a third-party system
such as PERMIS?  Some data resources offer very detailed authorisation
control, even to the level of an individual element in a very large
database.  It would seem impractical to reflect this level of
authorisation in an external authorisation system.

Question 2:
OGSA-DAI and DAIS both allow users to create new resources (e.g. result
sets from a query on a data resource). Hence we need to provide some
access control to these resources to control who has access to them.  Is
there a proposed solution to this that OGSA-DAI could look to adopt?


Observation 1:
You can do VO authorisation in different ways and at different levels of
granularity. For example, in BRIDGES we do a check when users log in to
the portal. They then get to see whatever services are appropriate with
their role in the VO. Following on from this, we can do all sorts of
finer grained authorisation "at the service level" based on who they are
and what they are trying to do. Thus do they get access to the National
Grid Service, ScotGrid or just the Condor pool when running a BLAST job.

You can define whatever policies you deem appropriate for data access
and release and do the checks at the authorisation level, but ideally we
want to have a model which scales. Hard-coding policies for table,
column, row access/use would work, but it ain't likely to scale up.
Another approach is also to look at static "user views" of the DB and
map these onto VO roles etc. This also has merit and would probably be
the most straightforward way to do the VO authorisation - DBMS
integration.

We are looking at patient consent and controlled attribute release
combined with a distributed, delegated trust model. We want to support
scenarios where patients can decide for what purpose their data/records
can be used, e.g. Cancer research, and we automate this into our
authorisation process including doing checks such as only if ethical
committee X has agreed to it.


Observation 2:
Assume your OGSA-DAI build is PERMIS protected. The "Create New
Resource" method can be protected at the VO level by a PERMIS policy.
Users are granted or denied access based not on their authenticated
identity but their role within the VO. So in your PERMIS policy you will
have a role defined which will carry the privilege of being able to
"Create New Resource" on your OGSA-D service. It is up to the Attribute
Authority at the resource to assign these roles in a trusted manner to
users, then as long as the AA is trusted by the policy (which it
necessarily does), the authorization has been done at as fine-grained a
level as you wish. 

[Dave: This is fine as far as it goes, but it doesn't seem to answer the
question of what access control should be assigned to the newly created
resource.  Perhaps we need some externalisation of these roles so that
the operation that creates the resource passes in a role (or some other
authorisation token).  Obviously each "creation" role would have to
specify which access roles could be assigned by the creator.]


Observation 3:
A major problem that we encountered with developing the PERMIS story at
the VO level was a Catch-22 in that we want to restrict who can retrieve
what data, based on what the data is, but we can only find out what the
data is by retrieving it. By which time it's too late and the user has
got the data anyway, whether or not they're authorised. 

The problem seemed to be inherent in the per-method mechanism that SAML,
and therefore PERMIS, uses to enforce authorization. David Chadwick
brought this up at the A&A working group at the GGF13 and proposed that
SAML be developed to include a per-parameter mechanism. If a parameter
could be sent along with the authorization request then this would allow
a trusted third-party to retrieve the data from the DB and make a
decision about what data to release to the user, before it gets back to
them.  GGF OK'd this and David Chadwick has a project to implement this.
This probably has implications as to how much control the DBA must give
up but we're not sure what they are yet...