Hello, all, I have roughly summarized some of the secuirty issues we have been discussing, although this is not a complete list. It was harder to summarize this discussion than I anticipated, so please free to make comments and additions. Ann Dave Berry wrote:
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...