<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffcc" text="#000000">
I agree with Estani, <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
IMHO. <br>
<br>
On 5/21/11 1:30 AM, Estanislao Gonzalez wrote:
<blockquote cite="mid:4DD77809.8040901@dkrz.de" type="cite">
<pre wrap="">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):
</pre>
<blockquote type="cite">
<pre wrap="">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:
<a class="moz-txt-link-freetext" href="http://test-datanode.jpl.nasa.gov/thredds/catalog.html">http://test-datanode.jpl.nasa.gov/thredds/catalog.html</a>
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
<a class="moz-txt-link-abbreviated" href="mailto:GO-ESSP-TECH@ucar.edu">GO-ESSP-TECH@ucar.edu</a>
<a class="moz-txt-link-freetext" href="http://mailman.ucar.edu/mailman/listinfo/go-essp-tech">http://mailman.ucar.edu/mailman/listinfo/go-essp-tech</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Gavin M. Bell
--
"Never mistake a clear view for a short distance."
-Paul Saffo
</pre>
</body>
</html>