[Go-essp-tech] resolution on securing opendap aggregations via ESGF

Mon May 23 05:25:53 MDT 2011

Yes, I'd agree with Estani and Stephen on this.

We've talked about interfaces in the federation at the institution -
institution level.  The same applies for the server-side: keeping a
separation of concerns between the access control layer and the app and
you get modularity.  You multiply by many times the reusability of the
security code.  I've seen this at CEDA where we've been able to reapply
the same access control middleware to many different HTTP based apps.

Also, access policy itself should be kept independent from data/metadata.
This is something we learnt here in the past with the NERC DataGrid.
There's a danger of mixing up the idea of roles with access control
policy.  Roles in themselves don't express an access policy, rather a rule
which may use a combination roles expresses some restriction e.g. If I
have this role OR this role I get access or Role A AND Role B I'm granted
and so on.  

Cheers,
Phil

On 23/05/2011 10:08, "stephen.pascoe at stfc.ac.uk"
<stephen.pascoe at stfc.ac.uk> wrote:

>
>I'm with Estani on this.  Authorisation decisions are best decoupled from
>the application where possible.  Phil is on leave today but I'm sure he'd
>say the same thing and give much more detailed reasoning.
>
>I think the catalogue already mixes slightly too much information
>together: location-independent file metadata and location-specific
>service information.  If we add access control it becomes too tightly
>coupled.
>
>Stephen.
>
>---
>Stephen Pascoe  +44 (0)1235 445980
>Centre of Environmental Data Archival
>STFC Rutherford Appleton Laboratory, Harwell Oxford, Didcot OX11 0QX, UK
>
>
>-----Original Message-----
>From: go-essp-tech-bounces at ucar.edu
>[mailto:go-essp-tech-bounces at ucar.edu] On Behalf Of Estanislao Gonzalez
>Sent: 21 May 2011 09:30
>To: Cinquini, Luca (3880)
>Cc: go-essp-tech at ucar.edu
>Subject: Re: [Go-essp-tech] resolution on securing opendap aggregations
>via ESGF
>
>Hi,
>
>In my opinion we shouldn't encode the access restriction in the catalog
>for these reasons:
>1) Changing the access would involved re-publishing the files. (this
>will be done for instance when QC L2 is reached CMIP5 Research -> CMIP5
>Commercial). And think about what would happen if we want to change the
>access restriction in a couple of years... we should publish everything
>again, and that would involve quite some effort to understand the
>procedure again...
>2) I'm not sure of this, but I fear TDS security cannot handle multiple
>roles. Right now you can publish to as many roles as required, and read
>and write access is kept separately. This would involve extending the
>TDS capabilities.
>3) There could be potential inconsistencies if the authorization service
>is detached from datanode (like with the gateway right now) and the
>publisher alters the role but forgets to cascade the changes to the
>authorizing service (which would proceed according to the last harvested
>info)
>4) And last but not least, I'm not sure we want to mix administration
>with publication. The publisher should only care about making data
>available, the administrator should organize this and be responsible for
>the security.
>
>So basically I don't agree :-) Although I do think, if required, we
>could change "esg-user" for "esgf-controlled" if it's more intuitive.
>
>My 2c anyways,
>Estani
>
>Am 20.05.2011 19:17, schrieb Cinquini, Luca (3880):
>> Hi,
>> 	a few points again on the issue of securing opendap aggregations
>>served by the TDS with ESGF filters:
>>
>> o There's a new release of the ESGF security filters (esg-orp 1.1.2)
>>that maps the TDS request URI to the dataset ID, and should solve this
>>problem. You can experiment with the JPL test TDS server:
>>
>> http://test-datanode.jpl.nasa.gov/thredds/catalog.html
>>
>> where the AIRS dataset (and aggregations) is secured, the MLS is not.
>>
>> o Now the data node authorization filter will correctly identify the
>>aggregation as secured, and call the configured authorization service.
>>Currently, the p2p Node authorization service can be configured to allow
>>authorization based on URL matching, so it will work. The gateway
>>authorization service will have to implement its own logic to establish
>>authorization.
>>
>> o Finally, I am wondering if we shouldn't change the way we encode
>>authorization in thredds catalogs. Right now, we use
>>restrictAccess="esg-user" for ALL collections, but should we consider
>>about encoding the proper required access control attribute instead, for
>>example restrictAccess="CMIP5 Research" ? Something to think about -
>>there are prons and cons about this - it's all a question on wether the
>>access control belongs in the catalog (and can be harvested for
>>searching...) or not.
>>
>> thanks, Luca
>> _______________________________________________
>> GO-ESSP-TECH mailing list
>> GO-ESSP-TECH at ucar.edu
>> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>
>
>-- 
>Estanislao Gonzalez
>
>Max-Planck-Institut für Meteorologie (MPI-M)
>Deutsches Klimarechenzentrum (DKRZ) - German Climate Computing Centre
>Room 108 - Bundesstrasse 45a, D-20146 Hamburg, Germany
>
>Phone:   +49 (40) 46 00 94-126
>E-Mail:  gonzalez at dkrz.de
>
>_______________________________________________
>GO-ESSP-TECH mailing list
>GO-ESSP-TECH at ucar.edu
>http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>-- 
>Scanned by iCritical.
>_______________________________________________
>GO-ESSP-TECH mailing list
>GO-ESSP-TECH at ucar.edu
>http://mailman.ucar.edu/mailman/listinfo/go-essp-tech

-- 
Scanned by iCritical.