[Go-essp-tech] Federation Registry Discussion

philip.kershaw at stfc.ac.uk philip.kershaw at stfc.ac.uk
Fri Feb 25 07:18:48 MST 2011 

Hi Luca,


>    interesting... the ESGF system is totally flexible in terms of what
>is an attribute type and an attribute value (they are just strings), but
>right now
>"CMIP5 Research" is a type, and the possible values are things like
>"Admin", "User", etc... We can certainly instead use "urn:esgf:pcmdi" as
>type, but then
>we would need to have values like "CMIP5 Research Admin" and "CMIP5
>Research User".... is this what we agreed on ?

I should have put that better.  It's best described in terms of SAML
attributes e.g. For a PCMDI Attribute Query:

Name: urn:esgf:pcmdi:grouprole
NameFormat (aka type): groupRole
value: two element tuple consisting of group and role value - group="CMIP5
Research", role="Admin"

What's needed is a means of describing the different attributes that are
under the governance of a given institution.  It's rather the namespace
prefix which sets this - for PCMDI in the above: urn:esgf:pcmdi

>Where's the ICD again ?

See the table containing the namespaces for different institutions:

http://esgf.org/wiki/Security/InterfaceControlDocument#VO_Attribute_Agreeme
nts

Cheers,
Phil

>   
>
>On Feb 25, 2011, at 4:53 AM, <philip.kershaw at stfc.ac.uk> wrote:
>
>> 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/attrib
>>ut
>> 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/attri
>>>bu
>>> teService.htm"/>
>>> 
>>>       <attribute type="Test Attribute"
>>> 
>>>service="http://localhost:8080/esgf-security/saml/soap/secure/attributeS
>>>er
>>> vice.htm"/>
>>> 
>>>       <attribute type="NASA OBS"
>>> 
>>>service="https://esg-datanode.jpl.nasa.gov/esgf-security/saml/soap/secur
>>>e/
>>> 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.
>

-- 
Scanned by iCritical.

More information about the GO-ESSP-TECH mailing list