[Go-essp-tech] Federation Registry Discussion
Nathan Wilhelmi
wilhelmi at ucar.edu
Fri Feb 25 20:21:23 MST 2011
Hi All,
If dropping the group_***_role_*** format for the attributes is on the
table I think we would be in support of that, at the least having the
discussion. On the gateway side it would require some work but I think
the end result would be an improvement.
Thanks!
-Nate
On 02/25/2011 06:00 AM, Cinquini, Luca (3880) wrote:
> Hi Phil,
> 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 ?
> Where's the ICD again ?
> thanks, Luca
>
> 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/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.
> _______________________________________________
> GO-ESSP-TECH mailing list
> GO-ESSP-TECH at ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
More information about the GO-ESSP-TECH
mailing list