[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ggf-ogsa-sec-wg] inter-domain requirements
Olle,
Thinking about the line between authorization assertions and policy
management I've come to the conclusion that SAML (and other)
authorization assertions are a form of policy management.
I can state in SAML "Olle has the right to do X for the next 15
minutes" and that is policy management. But SAML authorization
assertions are just a subset of policy management and don't support
the full range of statements you might want to make (like your
previous group example).
Von
Olle Mulmo writes (09:10 October 18, 2002):
>
> Von,
>
> You're right. So I'll cook up something new instead and try to make
> my point anyhow. :-)
>
> Think of a highly dynamical scenario, the extreme being a person that
> joins a VO, performs a single operation (copy a data set?), and
> then leaves.
>
> In order to facilitate such dynamics, the operational request probably
> has to be the carrier of some temporal change-of-policy information:
> "Give this person read access to dataset X for the next 15 minutes".
>
> [ ...or am I mixing up policy and authorization again now? ]
>
> My point: A truly dynamic grid requires both group membership assertions
> as well as (temporal) policy-change expressions to be used interchangably.
> One is really only a subset of the other.
>
> I have only browsed the first 20-30 pages so far, but from my limited
> understanding, XACML does seem to be much more along the lines of what
> I tried to depict above.
>
> /Olle
>
> -----Original Message-----
> From: Von Welch [mailto:welch@mcs.anl.gov]
> Sent: den 17 oktober 2002 22:09
> To: mulmo@pdc.kth.se
> Cc: Brian E Carpenter; ogsa-sec-wg@gridforum.org
> Subject: RE: [ggf-ogsa-sec-wg] inter-domain requirements
>
>
>
> 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
> >
>
>