[Go-essp-tech] Federation Registry Discussion
philip.kershaw at stfc.ac.uk
philip.kershaw at stfc.ac.uk
Mon Feb 28 04:34:54 MST 2011
I didn't think I'd hear myself say this ;) but I think we are best to stick with the Group/Role type for now.
The reason I'd say this is that we have just gone live with the system. There is still going to be lots to shake down and get working so best to leave this alone. By 'this' I mean the VO wide attributes 'CMIP5 Research' and 'CMIP5 Commercial': keep them in the Group/Role format. Once things have settled down a bit we could move to a simple single string type.
The system should AFAIK(!) already support both Group/Role and simple string types. That's at least what I've done with the Python based implementation here.
I think we should also keep the distinction clear between attributes (something about someone or something) and permissions (aka actions which are permitted on a given resource). Actions are within the realm of the authorisation process. Rules in an authorisation service bind those attributes and actions together to determine restrictions on a given resource.
Cheers,
Phil
From: "Gavin M. Bell" <gavin at llnl.gov<mailto:gavin at llnl.gov>>
Date: Sun, 27 Feb 2011 10:11:47 -0800
To: Estanislao Gonzalez <estanislao.gonzalez at zmaw.de<mailto:estanislao.gonzalez at zmaw.de>>
Cc: "go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu>" <go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu>>
Subject: Re: [Go-essp-tech] Federation Registry Discussion
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><mailto: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"<https://esg-test1.llnl.gov/esgf-security/saml/soap/secure/attributeService.htm>/>
Cheers,
Phil
On 23/02/2011 12:37, "Cinquini, Luca (3880)"<Luca.Cinquini at jpl.nasa.gov><mailto: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"<https://esg-test1.llnl.gov/esgf-security/saml/soap/secure/attributeService.htm>/>
<attribute type="Test Attribute"
service="http://localhost:8080/esgf-security/saml/soap/secure/attributeSer
vice.htm"<http://localhost:8080/esgf-security/saml/soap/secure/attributeService.htm>/>
<attribute type="NASA OBS"
service="https://esg-datanode.jpl.nasa.gov/esgf-security/saml/soap/secure/
attributeService.htm"<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<mailto: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<mailto:estanislao.gonzalez at zmaw.de>
Rachana Ananthakrishnan
Argonne National Lab | University of Chicago
_______________________________________________
GO-ESSP-TECH mailing list
GO-ESSP-TECH at ucar.edu<mailto: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<mailto: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<mailto: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<mailto: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
_______________________________________________ GO-ESSP-TECH mailing list GO-ESSP-TECH at ucar.edu<mailto:GO-ESSP-TECH at ucar.edu> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
--
Scanned by iCritical.
More information about the GO-ESSP-TECH
mailing list