[Go-essp-tech] Federation Registry Discussion

Wed Feb 23 05:37:02 MST 2011

Hi Rachana,
	I thought about another thing: the ESGF registry should also contain the mapping of access control attribute types to their respective attribute services. So, for example, the "CMIP5 Research" attribute type should be mapped to https://<pcmdi host>/esgf-security/saml/soap/secure/attributeService.htm  so that clients that need to execute authorization decisions know where the user attribute values for that type are managed.

For example, this is a way to hold the same information in an XML configuration file:

        <attribute type="CMIP5 Research" service="https://esg-test1.llnl.gov/esgf-security/saml/soap/secure/attributeService.htm"/>

        <attribute type="Test Attribute" service="http://localhost:8080/esgf-security/saml/soap/secure/attributeService.htm"/>

        <attribute type="NASA OBS" service="https://esg-datanode.jpl.nasa.gov/esgf-security/saml/soap/secure/attributeService.htm"/>

which I think should be transferred to a federation-wide registry.

thanks, Luca

On Feb 22, 2011, at 7:24 AM, Rachana Ananthakrishnan wrote:

> Hi Estani,
> 
> Thanks for the comments. 
> 
>> 
>> I have a couple of remarks regarding the PKI:
>> - I'd suggest we concentrate on one of the two forms of storing the CAs, preferably the PEM certificates. The node/gateway can then use a script to generate the truststore periodically or, better yet, on demand. This will avoid problems regarding inconsistencies.
> 
> This was the original proposal, and the plan was to keep it as PEM certificates. But there was push back on this, we were asked to keep both for convenience. Maybe Luca can comment here, I know he expressed concern over the error prone translation to the Java KeyStore format. 
> 
>> - by embedding the PEM certificates in the xml file both registry and CA information can be held together from the very beginning.
> 
> That is an interesting idea. I was planning on pushing for a web form that allows both the registry.xml contents and the PEM files, but this might make it more tightly coupled.
>> 
>> And regarding the xml file exchange format, this is something that should be discussed between the registry service and the node/gateway developers. Still I just wanted to point out that the GatewayNode does not contain the Gateway name, which is rather important.
> 
> Yes, definitely, this is a call for feedback, and input on these is useful.
> 
> Regarding the Gateway name, I was thinking that the namespace and hostname combination would provide a node name. Would that not suffice? But if it would be easier to have another attribute, we can do that.
>> 
>> On the other hand, the idea of using git as an ingest engine seems IMHO perfect to start with. I would then propose that every institution manage it's own project (one per gateway and might be hosted anywhere) where all the required directories and files are listed and kept up to date (but only store PEM certificates, no truststores ones). Then PCMDI can have a "repository" project linking at each subproject named simply after the gateway name (keyword: git-submodule). This way only the gateway admins have write access to their respective projects and PCMDI to the central repository (scripts for transforming PEM into truststore, creating tars, etc). This helps keeping things tidy and properly administrated in my opinion. The node manager can have access to the same git repository of the owning gateway and update there the required data (Service endpoints, CAs, etc). PCMDI will periodically update all submodules and generate the required files (tar balls, etc) which can be accessed from every node/gateway with read-only rights.
>> 
> 
> This is the exact same proposal Neill and I had when we started this effort: simply to use the versioning system for this, and partition the space for each site administrator. This provides us a functional system, with low overheads for deployment, and a good start. But I think Gavin is looking at it from a more medium-term perspective, and including it with the data node manager functionality for cleaner automation and auto-populate configuration information. I don't want to speak for him, so I'll let Gavin elaborate. 
> 
> It might be worth meeting on this topic, so all of us are on the same page on timelines, and plans.
> 
> Thanks,
> Rachana
> 
>> This can evolve later on to services that upload/download data from the registry without using git.
>> 
>> Just an idea...
>> 
>> Thanks,
>> Estani
>> 
>> Am 22.02.2011 00:10, schrieb Rachana Ananthakrishnan:
>>> For the next release, we are targeting a federation registry that will provide a store for information about the various ESGF nodes and services, and also the trusted CA information. This page provides some background on the work, and also link to the proposed schema to represent the information:
>>> 
>>> http://esgf.org/wiki/FederationRegistry
>>> 
>>> Neill has completed work on ingestion of this data: that is form to obtain the data about a node, and communicate it to a service. Gavin is now working on integrating it with the Data Node Manager, such that the data is stored on a central server at PCMDI and then can be downloaded by other nodes.
>>> 
>>> Please review and comment.  The document is still sparse on the protocol for exchanging this information, but I am initiating this discussion so we can drive to consensus on the schema atleast.
>>> 
>>> This service is critical in keeping meta data about the federation curated and distributed, so should be a high priority for next release. It would be useful to table this topic on the next go-essp call. (Not sure if we plan for one tomorrow, Feb 22)
>>> 
>>> Thanks,
>>> Rachana
>>> 
>>> Rachana Ananthakrishnan
>>> Argonne National Lab | University of Chicago
>>> 
>>> _______________________________________________
>>> 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:  estanislao.gonzalez at zmaw.de
>> 
> 
> Rachana Ananthakrishnan
> Argonne National Lab | University of Chicago
> 
> _______________________________________________
> GO-ESSP-TECH mailing list
> GO-ESSP-TECH at ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech