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

[Gary Ellison <gary.ellison@sun.com>]

>>>>> " " == Von Welch <welch@mcs.anl.gov> writes:

I agree SAML is not intended as a means to express policy although XACML is.

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


--
mailto:gary.ellison@sun.com
"In the rich man's house there is nowhere to spit but in 
 his face" -- Diogenes