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

[Ann Chervenak]

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...
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: securityIssues.doc
Type: application/msword
Size: 46080 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-d-wg/attachments/20050719/31209e07/attachment.doc