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

[Dave Berry]

David's e-mail bounced.

-----Original Message-----
From: David Chadwick <d.w.chadwick at kent.ac.uk>
Organization: University of Kent
MIME-Version: 1.0
To: Dave Berry <daveb at nesc.ac.uk>
Cc: ogsa-d-wg at ggf.org, Takuya Mori <moritaku at bx.jp.nec.com>,
	Frank Siebenlist <franks at mcs.anl.gov>,
	Von Welch <vwelch at ncsa.uiuc.edu>,
	Richard Sinnott <ros at dcs.gla.ac.uk>, Ally Hume
<ally at 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:
> 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?

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
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...
> 
> 

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 at 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

*****************************************************************