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

[Cinquini, Luca (3880)]

Hi Estani,
	it might be too late to change how we encode the catalogs... but for the sake of argument, let me discuss your points, in a pure
philosophical spirit:

On May 21, 2011, at 2: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...

yes,,all datasets would need to be republished. But republishing is easy! Once you have a script to publish
a dataset, you simply run it again. I personally think that all information about a dataset belongs in the catalog:
so when a dataset is promoted from QC1 to QC2, it should be republished, so that information can be harvested.
It's true that we could achieve more decoupling by encoding QC and access control information on separate sources,
but at the expense of a) more complexity when the information is merged together and b) more dependencies.
So, IMO, a catalog should contain both QC information and access control information. The catalog version can track
the evolution of the dataset as it gets promoted through the QC levels.

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

Not necessarily. We actually don't use the TDS access control, except for the fact that it we query it to figure out wether or not a
catalog is restricted, then we hand over all other processing to the authorization service. What I think would be best to do is not just 
query the TDS for a simple yes/no, but query it for the specific group/role to which that catalog is restricted. This can be a multi-valued string,
since it is then passed for processing to the ESGF facilities.

> 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)
I am not sure we should necessarily worry about the publisher forgetting to perform the last step of the publishing (the push),
but if we did, we could make the authorization service be handed the role read from the catalog at request time, so that no
inconsistency would be possible: that role would be compared against the role retrieved from the
attribute service at that time. In other words, the authorization service (at the gateway or anywhere else)
would not have to store the roles at all.

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

I do share your concern, but it's a tradeoff: decoupling versus simplicity and internal consistency, I think...
> 
> 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.

It's ok... unless there is an overwhelming expression of support, we will keep things as they are.

thanks, Luca
> 
> 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
>