[Go-essp-tech] Federation Registry Discussion
Estanislao Gonzalez
estanislao.gonzalez at zmaw.de
Sat Feb 26 10:18:49 MST 2011
Hi Nate,
if you mean dropping the role part, I agree too. I think it's simple and
more flexible. There are two modes (write/read) and the security
mechanism already allow multiple groups to be defined for securing any
dataset, which should be enough. The role could still be used by
expanding the group name to group-role in those cases where it make sense.
But I think it will be cleaner to say there are just plain old groups
and nothing else. cmip5-bdm, cmip5-publisher might all be better handled
as groups in my opinion.
Thanks,
Estani
Am 26.02.2011 04:21, schrieb Nathan Wilhelmi:
> 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
> _______________________________________________
> 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
More information about the GO-ESSP-TECH
mailing list