[Go-essp-tech] Federation Registry Discussion

Fri Feb 25 04:53:04 MST 2011

Hi Luca,

I'm glad you raised this.  I think it's an important piece for the
registry.

I would draw the distinction between attribute name and type though.
"CMIP5 Research" is an attribute name of type "urn:esgf:pcmdi" (from the
ICD) so your example would become:

<attribute type="urn:esgf:pcmdi"
service="https://esg-test1.llnl.gov/esgf-security/saml/soap/secure/attribut
eService.htm"/>

Cheers,
Phil

On 23/02/2011 12:37, "Cinquini, Luca (3880)" <Luca.Cinquini at jpl.nasa.gov>
wrote:

>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/attribu
>teService.htm"/>
>        
>        <attribute type="Test Attribute"
>service="http://localhost:8080/esgf-security/saml/soap/secure/attributeSer
>vice.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
>
>_______________________________________________
>GO-ESSP-TECH mailing list
>GO-ESSP-TECH at ucar.edu
>http://mailman.ucar.edu/mailman/listinfo/go-essp-tech

-- 
Scanned by iCritical.