[Go-essp-tech] Federation Registry Discussion

philip.kershaw at stfc.ac.uk philip.kershaw at stfc.ac.uk
Tue Mar 1 01:45:54 MST 2011 

Hi Luca and all,

Meant to follow up on this earlier...

On 27/02/2011 12:31, "Cinquini, Luca (3880)" <Luca.Cinquini at jpl.nasa.gov>
wrote:

>    ok for using attribute names such as "urn:esgf:pcmdi", as previously
>agreed. 

This is something that was agreed at the Sept ANL meeting but has not yet
been implemented AFAIK.  The tasks are listed in the Security Priorities
4.x items:

http://esgf.org/wiki/Security/SecurityPriorities

It's really important for the federation that names are correctly
constrained to their issuing authority e.g. Only PCMDI has the authority
to issue the VO wide attribute name urn:esgf:pcmdi:grouprole [whose values
include (CMIP5 Research, default) and (CMIP5 Commercial, default)]

It's something that should be in the federation registry I think but not
sure how best to do it, perhaps an entry which constrains a given
authority to only issues attribute names adhering to a given namespace.

>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).

We support both - the ESG group/role type so that we can manage the VO
attribute urn:esgf:pcmdi:grouprole but we also allow for simple string
attribute values for use with our own datasets.

Cheers,
Phil

>
>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_Agree
>>me
>> 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/attr
>>>>ib
>>>> 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/att
>>>>>ri
>>>>> bu
>>>>> teService.htm"/>
>>>>> 
>>>>>      <attribute type="Test Attribute"
>>>>> 
>>>>> 
>>>>>service="http://localhost:8080/esgf-security/saml/soap/secure/attribut
>>>>>eS
>>>>> er
>>>>> vice.htm"/>
>>>>> 
>>>>>      <attribute type="NASA OBS"
>>>>> 
>>>>> 
>>>>>service="https://esg-datanode.jpl.nasa.gov/esgf-security/saml/soap/sec
>>>>>ur
>>>>> 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.

-- 
Scanned by iCritical.

More information about the GO-ESSP-TECH mailing list