[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ggf-ogsa-sec-wg] Two documents



Olle,

 This gets at one of the fundamental tensions we had when drafting
this - how much information to include in the request?

 One could easily imagine a very fine-grained PDP that could use the
whole certifiate chain and parameters of the request to render
decisions.

 And then one can also imagine a world with mostly coarser grained
PDPs that really don't want that much detail, and considering that we
could be talking large volumes of information in the parameters (and
maybe even the cert chain) shipping all this information all the time
could be horribly inefficient.

 And my guess would be that the granularity won't be consistent for
any PDP - for some actions it may want lots of information, for others
very little.

 Working under the assumption that one is not going to include all the
information needed in the request all of the time, there needs to be a
method of handling these cases when the information needed isn't
there. Looking around at authorization APIs one way of handling this
is the conditional response, where essentially you return policy to
the requestor for which the PDP doesn't have the necessary
information.

 SAML Condition elements seem to be have created to fill this role.
So, another way of going at this would be to just include an identity
and then allow the response to carry a condition on it's response -
e.g. "Request OK, if not using a proxy with lifetime greater than 7
days". A requestor would then have the onus of evaluating the
conditions (or failing if it can't parse them).

Thoughts?

Von

Olle Mulmo writes (11:49 February 17, 2003):
 > 
 > A quick glance triggered a quick comment:
 > 
 > 5.1.1 Subject Element
 > "The SAML specification defines a URI for X.509 subject
 > names (#X509SubjectName) that SHOULD be used for GSI authenticated identities."
 > 
 > GSI credentials may include delegation and other assorted information
 > that is of interest. Thus, a single subject name is often not enough.
 > Just see various rationales for the recent GT2 authorizaiton callout
 > extensions, that take a credential as parameter instead of a subject
 > name.
 > 
 > I think you should add a recommendation that people SHOULD also use the
 > <SubjectConfirmation> element and add their binary token(s) in the
 > <ds:keyInfo> contained in there. Except when it would be an obvious and
 > unnecessary exercise, of course -- but it may be hard to know in what silly
 > context a particular SAML assertion will end up in a distributed, loosely
 > coupled world. Having a default situation in which as much tracing
 > information as possible is provided in our tokens seems like a good thing
 > to me.
 > 
 > Also consider Kerberos credentials and UNIX user names: Do we reuse the
 > SAML #emailAddress and/or #WindowsDomainQualifiedName formats? The string
 > formats happen to be the same, but the semantics are different: it would
 > therefore seem like an ugly hack to me. I suggest you create additional
 > NameIdentifier format URIs for these cases.
 > 
 > BTW, does a username without the optional domain name and no NameQualifier
 > mean user@localhost? If so, the localhost of whom? The target or the
 > source of the SAML document?
 > 
 > /Olle
 > 
 > -----Original Message-----
 > From: owner-ogsa-sec-wg@gridforum.org
 > [mailto:owner-ogsa-sec-wg@gridforum.org]On Behalf Of Von Welch
 > Sent: den 15 februari 2003 21:19
 > To: ogsa-sec-wg@gridforum.org
 > Cc: Frank Siebenlist; Laura Pearlman; Samuel Meder
 > Subject: [ggf-ogsa-sec-wg] Two documents
 > 
 > 
 > 
 > All-
 > 
 >  We have a pair of documents we are submitting to you, the OGSA
 > Security Working group, for consideration. Both of these documents
 > represent bottom-up draft specifications of work we are actively
 > doing. We like to get input from the community and derive GGF
 > specifications from these drafts.
 > 
 > The documents are:
 > 
 >     *  "Use of SAML for OGSA Authorization"
 > 
 >     * "A GSSAPI profile for security context establishment and message
 > protection using WS-SecureConversation and WS-Trust"
 > 
 >  Both of these documents have been submitted to the GGF webmaster for
 > posting on the document page. They are also available now at:
 > 
 > http://www.globus.org/ogsa/Security/
 > 
 > We will also send a note to the WG chairs and ask for discussion time
 > at GGF7.
 > 
 > Regards,
 > 
 > Von (for Frank, Laura, Sam and Von)
 > 
 > p.s. I'm writing this as I pack for vacation for a week so please be
 > sure to cc my colleagues during this time on any questions.
 > 
 >