RE: [ggf-ogsa-sec-wg] inter-domain requirements

[Von Welch <welch@mcs.anl.gov>]

Olle,

 It seems to me that your example, "any guy from XYZ tech support has
access rights to any of the systems that we have bought from XYZ
corporation.", is a policy assertion.

 While doing policy assertions could certainly be useful, it strikes
me as a different thing that attribute, group, identity
assertions. And I agree with you SAML doesn't cover them (I don't
believe it was intended to).

Von

Olle Mulmo writes (18:28 October 11, 2002):
 > 
 > Brian,
 > 
 > There was some discussions of a "club membership" approach recently.
 > In such discussions, the dynamic part of an intra-enterprise trust
 > relationship is simple: aquire the membership token. Once you have
 > that, more or less static M-to-N assertions fix the rest.
 > 
 > With M-to-N assertions I mean expressions like "any guy from XYZ tech
 > support has access rights to any of the systems that we have bought
 > from XYZ corporation."
 > 
 > The reason I'm pointing this out is that in it's current incarnation,
 > SAML only deals with 1-to-N assertions, so we would probably need to
 > tweak and bend things a bit in this scenario -- but it's doable.
 > 
 > Is the club membership model something you foresee, or are you heading
 > for an entirely dynamic model?
 > 
 > /Olle
 > 
 > -----Original Message-----
 > From: owner-ogsa-sec-wg@gridforum.org
 > [mailto:owner-ogsa-sec-wg@gridforum.org]On Behalf Of Brian E Carpenter
 > Sent: den 11 oktober 2002 15:31
 > To: ogsa-sec-wg@gridforum.org
 > Subject: [ggf-ogsa-sec-wg] inter-domain requirements
 > 
 > 
 > I'd hoped to do a bit more work on this before now but
 > events conspired against that. However, I've added a few
 > more remarks below to what I said earlier:
 > 
 > > One possible way of staging security reqts, at least viewed from
 > > an industrial deployment view, is
 > >  Stage 1: the single-enterprise scenario (what some people call an intragrid)
 > >  Stage 2: the inter-enterprise scenario (extragrid)
 > >  Stage 3: the general case (intergrid).
 > > The issues of trust relationships, PKI, and security assertions
 > > get progressively harder as you go through these three stages.
 > > 
 > > This may seem a bit odd in the research community which probably
 > > thinks it's in Stage 3 already, but the reality I think is nearer
 > > Stage 1.5. As somebody pointed out recently, establishing trust
 > > relationships etc is a major headache in setting up a grid
 > > and I think we will need to analyse that in terms of technical
 > > requirements for the stages mentioned above.
 > 
 > Phil Janson and I have been discussing some ideas about the inter-enterprise
 > scenario. It seems to us that in general you will need to transfer
 > security assertions between separate domains inside a given VO, and that
 > if we think just in terms of how to interconnect Kerberos and X.509
 > domains we won't get the requisite generality. 
 > 
 > The physical organisations taking part in a VO share resources and services, 
 > and will negotiate a trust model, but we have to assume they have different
 > user identity systems, different authentication regimes, and separate 
 > authorization policy domains. 
 > 
 > We think that to link these system/regimes/domains, there is
 > a requirement for an abstraction that will serve to represent
 > a set of security assertions in a canonical format. There could
 > also be a concrete from of that abstraction for use in inter-domain
 > security exchanges.
 > 
 > We also think (oops, this is as close to a solution as a requirement)
 > that the representation of this abstraction should be in SAML for two 
 > reasons:
 > 
 > 1. SAML can readily be transmitted using SOAP, and protected using 
 > WS-Security. 
 > 
 > 2. While X509 and Kerberos are popular and powerful security assertion
 > syntaxes, they predate enough modern thinking on SAs that they lack 
 > fields to cover some possible semantics (e.g. authentication method and 
 > context) and are not as easily extensible as SAML.
 > 
 > We have a few more ideas but they are not quite cooked enough yet.
 > 
 >    Brian
 >