[Go-essp-tech] Federation Registry Discussion

Cinquini, Luca (3880) Luca.Cinquini at jpl.nasa.gov
Sun Feb 27 05:31:18 MST 2011 

Hi Phil,
	ok for using attribute names such as "urn:esgf:pcmdi", as previously agreed. As for the types, I thought at BADC you did not use (group,role) pairs but rather simple strings ? That would also be my preference because it would allow us to move away from proprietary ESG formats and handling of SAML assertions (although I know that defining custom types is one of SAML features).
thanks, Luca

On Feb 25, 2011, at 7:18 AM, <philip.kershaw at stfc.ac.uk> <philip.kershaw at stfc.ac.uk> wrote:

> 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