Hi Jens, others, Brian and I are having discussions about extensions to the XACML interoperability profile http://www.ogf.org/documents/GFD.205.pdf (or https://redmine.ogf.org/dmsf/fedsec-cg?folder_id=6535) How should we go about this? We're currently still discussing possible ways of adapting, but ultimately it should lead to a new standard we both want to adopt. If I understood correctly, GFD.205 was mostly guided within the fedsec group. Secondly, together with John White, I hope to write an XACML profile aimed at provising and managing virtual machines. Some background: we -- Nikhef -- have developed an XACML-talking 'Execution Environment Service' that can run as backend to the EMI Argus service [1]. It typically runs one or more plugins to do the hard work, and John White has been developing a OpenStack plugin which should be able to boot up VMs with proper authorization. In order for this to all work, we need to develop a new profile for passing information around, such as user identities, VM hostnames etc., new action and resource attributes and ways to encapsulate the authorization policies. As far as I know, this is pretty much uncharted territory. Again, what would be the best way to start with this? Cheers, Mischa [1] Design of the Execution Environment Service https://edms.cern.ch/document/1018216/1 -- Nikhef Room H155 Science Park 105 Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msalle@nikhef.nl __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
Hi Mischa, Thanks for your mail. The GFD.205 document should be the basis for authorisation interoperation but if more stuff is needed, a revision or a supplementary document could be the way to do it. For extensions to the profile, perhaps a supplementary document. GFD.205 was formally at home in FEDSEC, but hopefully public comments would have come from all the OGF "community" . For now I suggest gathering the any new stuff you propose and then we can see how to amend or otherwise document that. As regards your SAML profile for execution environments, I would suggest starting with what you need and then later we could try to identify what is common - and what is different - compared to other similar profiles. For example, in EUDAT we are experimenting with SAML profiles - well, *cough* we did some work back in March for ISGC2014 - but the idea is to have a federation-level management of authorisation, so all the different communities are managed in a consistent way across the federation, even if their source of authorisation comes from different AAs. This profile would also need user identities, and hostnames or at least site identities (as not all sites support all communities), so it would be interesting to look for overlaps as well. Of course we should not try to force overlaps where none is needed. I would suggest outlining documents with requirements and thoughts for now, and then circulate to fedsec and other Usual Suspects, and we can then see if we can identify common areas with related work - and if we want to. In the worst case you will have a sort of writeup already which you could turn into an OGF document. But my thinking is that if we can identify some common ground, which we could usefully try to do in OGF, then that would be interesting, might increase the opportunity for interoperation or reduce the work required somewhere. Cheers --jens
Hi Jens, thanks for the extensive answer! On Tue, Sep 23, 2014 at 04:13:43PM +0100, Jens Jensen wrote:
Thanks for your mail. The GFD.205 document should be the basis for authorisation interoperation but if more stuff is needed, a revision or a supplementary document could be the way to do it. For extensions to the profile, perhaps a supplementary document. GFD.205 was formally at home in FEDSEC, but hopefully public comments would have come from all the OGF "community" . For now I suggest gathering the any new stuff you propose and then we can see how to amend or otherwise document that. Okee, very good. That is probably easier for us in any case.
As regards your SAML profile for execution environments, I would suggest starting with what you need and then later we could try to identify what is common - and what is different - compared to other similar profiles. For example, in EUDAT we are experimenting with SAML profiles - well, *cough* we did some work back in March for ISGC2014 - but the idea is to have a federation-level management of authorisation, so all the different communities are managed in a consistent way across the federation, even if their source of authorisation comes from different AAs. This profile would also need user identities, and hostnames or at least site identities (as not all sites support all communities), so it would be interesting to look for overlaps as well. Of course we should not try to force overlaps where none is needed. This sounds interesting, and also reminds me of the work with Oscar worked on with CLARIN just before he left. Btw, I presume you mean an XACML profile? Is there anything written up already, apart from http://indico3.twgrid.org/indico/materialDisplay.py?contribId=134&sessionId=29&materialId=slides&confId=513 ? One problem will be that we are probably stuck with XACML2, since we use existing tools build on SAML2-XACML2. We could perhaps make two branches. AFAIU XACML3 mainly adds (some very useful) things.
I would suggest outlining documents with requirements and thoughts for now, and then circulate to fedsec and other Usual Suspects, and we can then see if we can identify common areas with related work - and if we want to. In the worst case you will have a sort of writeup already which you could turn into an OGF document. But my thinking is that if we can identify some common ground, which we could usefully try to do in OGF, then that would be interesting, might increase the opportunity for interoperation or reduce the work required somewhere. Okee, that sounds like a good idea. We will do that.
Cheers, Mischa -- Nikhef Room H155 Science Park 105 Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msalle@nikhef.nl __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
Hi Jens, to come back to the GFD.205 discussion: we have been working on the extensions and agree now on what's needs to be done. The result has already been or is being implemented in the relevant clients (primarily the lcmaps-plugins-scas-client) and servers (primarily GUMS). The set of changes plus their rationale are all described in a new proposed document which I've attached. It would be an addition to, not replacement of the original document. How we should go from here? Best wishes, Mischa On Wed, Sep 24, 2014 at 12:42:54PM +0200, Mischa Salle wrote:
Hi Jens,
thanks for the extensive answer!
On Tue, Sep 23, 2014 at 04:13:43PM +0100, Jens Jensen wrote:
Thanks for your mail. The GFD.205 document should be the basis for authorisation interoperation but if more stuff is needed, a revision or a supplementary document could be the way to do it. For extensions to the profile, perhaps a supplementary document. GFD.205 was formally at home in FEDSEC, but hopefully public comments would have come from all the OGF "community" . For now I suggest gathering the any new stuff you propose and then we can see how to amend or otherwise document that. Okee, very good. That is probably easier for us in any case.
-- Nikhef Room H155 Science Park 105 Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msalle@nikhef.nl __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
Hi Mischa, Interesting: I would suggest publishing it as a supplementary document - with its own GFD number, and a public review? As you say, it doesn't replace the other document, but it is a result of experiences with the original profile. Regards --jens
On Wed, Dec 10, 2014 at 04:22:41PM +0000, Jens Jensen wrote:
Hi Mischa,
Interesting: I would suggest publishing it as a supplementary document - with its own GFD number, and a public review? As you say, it doesn't replace the other document, but it is a result of experiences with the original profile.
Hi Jens, yes, that sounds like a good idea. What should we do next? Are there any obvious things we need to change beforehand? Best wishes, Mischa -- Nikhef Room H155 Science Park 105 Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msalle@nikhef.nl __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
participants (3)
-
Jens Jensen -
Jens Jensen -
Mischa Salle