[Go-essp-tech] Federation Registry Discussion
Gavin M. Bell
gavin at llnl.gov
Sun Feb 27 11:11:47 MST 2011
Hi,
I think that much of this depends on what the authorization and
authentication system wants. I am not clear on what this part of the
system requires. However, modulo this.... I think we go back to UNIX
style and have groups and then have r,w,x like "roles" - map to
something like "reader (visibile), publisher, admin" (for example). That
roles list we are free to expand as needed, but pretty much be these
few. I don't expect roles values to change really. And yes, make up
all the groups that are necessary.
It works for UNIX - so it's good enough for us, right? I agree with
Estani, but again I am not sure of the other constraints imposed by how
the authz/authn systems work.
On 2/26/11 9: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
>
--
Gavin M. Bell
--
"Never mistake a clear view for a short distance."
-Paul Saffo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20110227/250f3786/attachment-0001.html
More information about the GO-ESSP-TECH
mailing list