[Fedsec-cg] XACML profiles

Mischa Salle msalle at nikhef.nl
Wed Sep 24 06:42:54 EDT 2014


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 at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4332 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/fedsec-cg/attachments/20140924/23f02ff3/attachment.bin>


More information about the Fedsec-cg mailing list