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

["Takashi Kojo" <tkojo@mvi.biglobe.ne.jp>]

Olle,

This is a bit older subject which might have been talked. But
will you describe briefly about the Membership in regard to
M-to-N and 1-to-N difference? To me, it seems 1-to-N would
perform equivalent to M-to-N with existence of certain user
directory assistance.

Kojo


> 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
>
>