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
David's e-mail bounced. -----Original Message----- From: David Chadwick <d.w.chadwick@kent.ac.uk> Organization: University of Kent MIME-Version: 1.0 To: Dave Berry <daveb@nesc.ac.uk> Cc: ogsa-d-wg@ggf.org, Takuya Mori <moritaku@bx.jp.nec.com>, Frank Siebenlist <franks@mcs.anl.gov>, Von Welch <vwelch@ncsa.uiuc.edu>, Richard Sinnott <ros@dcs.gla.ac.uk>, Ally Hume <ally@epcc.ed.ac.uk> Subject: Re: Summary of a conversation on security Hi Dave I have tried to answer some of your questions below, esp. the ones that refer to PERMIS Dave Berry wrote: 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?
In essence these are two hurdles that the subject has to jump over before he gains access to the data. First he has to get past PERMIS, then past the local access control scheme. In some scenarios the local scheme may be subordinate to PERMIS (if it trusts it sufficiently), and can give total access rights to the PEP (ie. the PEP is deemed to be an administrator). The PEP calls PERMIS to make decisions about the access control policy, and then it enforces the decision (grant or deny). In this case the only local access controls will be administrator/all. In other scenarios this is not feasible nor desirable. For example, when granting access to individual data fields in a database, it isnt possible to write a PERMIS policy for this since you would have to repeat the data items in the PERMIS policy (as targets). Thus you still need the internal access control lists for fine grained control. 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.
Exactly my point above
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?
It is possible to create new PERMIS policies, since they are XML data structures, via a programmable interface. So the job that creates the data resource could also create a PERMIS policy for access to it. The job would then need to tell the SOA to sign this policy, and the PEP to load it, then it could be enforced. The automated management of policies is not currently part of the PERMIS release, but it is something we will be working on as part of the TrustCoM project over the next 18 months.
Observation 1: You can do VO authorisation in different ways and at different levels
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
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
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
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
of the the that this.
This probably has implications as to how much control the DBA must give up but we're not sure what they are yet...
There are at least two issues here. Firstly the passing of the parameter from the user's request to the PDP. SAML does not support this, so we have to move on from the current OGSA Authzn profile to a more functional one. XACML does support the passing of parameters, so it is likely that XACML will become the profile for OGSA Authzn v2. Secondly, once the parameter is available to the PEP, who makes the authorisation decision, is it the PEP or the PDP or the DB itself? i) PDP. PERMIS is already capable of making the decision providing the PEP retreives the data item from the DB and passes this along with the user parameter to PERMIS. ii) PEP. PERMIS cannot currently pass the policy back to the PEP for it to make the decision. Thus would fall under the banner of returning conditions or obligations from the PDP to the PEP, which PERMIS currently does not support. Although in our plans we do propose to add obligations to PERMIS in due course (sorry I cant give timescales for this yet). iii) DB. The PEP could pass the parameter to the DB and let it make the decision as part of its local access control mechanism. But this is a decision for the application builder to determine. I hope the above are helpful to you regards David -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************