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

[Bryan Lawrence]

For what it's worth, I agree too ... it's far better to make many of 
these "joins" via a query than lump them together and then have to 
manage multiple versions since all the information resources have very 
different governance and update cycles.

Cheers
Bryan

> I agree with Estani,
> 
> The basic rule of thumb is to NOT put anything more in the catalogs,
> this includes CIM information as well as the more recent talk about
> access restrictions.
> 
> Catalogs can be universally identified with their id. Any ancillary
> in formation should be augmented with the datasetids that they
> reference and at presentation time or query time we pretty much do a
> join to pull in all information referencing the datasetid.  This
> will limit the number of of times publishing has to take place.  It
> also simplifies other areas of functionality that I have been
> thinking about.
> 
> The only time we should be changing the catalog is if the files they
> logically represent change - i.e. something that changes their
> checksum values.
> 
> IMHO.
> 
> On 5/21/11 1:30 AM, Estanislao Gonzalez wrote:
> > 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

--
Bryan Lawrence
Director of Environmental Archival and Associated Research
(NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC)
STFC, Rutherford Appleton Laboratory
Phone +44 1235 445012; Fax ... 5848; 
Web: home.badc.rl.ac.uk/lawrence