[Go-essp-tech] Federation Registry Discussion

Nathan Wilhelmi wilhelmi at ucar.edu
Sat Feb 26 11:03:49 MST 2011 

Hi,

That is exactly what I am thinking, well I don't think we have had any 
discussions internally where we saw the need for the role to be part of 
the group. This has a few consequences on the UI in the gateway. Namely 
the number of groups increases, but I believe this can be solved by 
enhancing the user interface. We most likely move away from the simple 
multi-select list boxes and replace it with some better group searching 
and filtering capabilities to make it easy to select groups. This also 
removes the string concatenation and parsing operations for working with 
the current role-in-a-group model internally, so far this as worked but 
it does make it simpler.

Thanks!

-Nate

On 02/26/2011 10:18 AM, Estanislao Gonzalez wrote:
> 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
>
>

More information about the GO-ESSP-TECH mailing list