[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] SAML Authn Ctx Combination Spec
Hi Tom, below paul Thomas Wisniewski wrote: > > Paul, I see what you mean. > > Basically, you want the text to say that only one "top-level" > RequestedAuthnContexts element is allowed. But 0 or more second-level > RequestedAuthnContexts elements are ok. > yes > > The other questions I had were: > > - the meaning of RACComparison in relation to a RequestedAuthnContexts > element that has RequestedAuthnContexts sub-elements and those that don't. > if a <rac:RequestedAuthnContexts> element has child <rac:RequestedAuthnContexts> elements, then any RACComparison attribute on the parent applies to the processing of those children, each of which should produce a single authn context to bubble up into the top-level operation. > > For those RequestedAuthnContexts that do not have > RequestedAuthnContexts sub-elements, it seems that "all" should not be > used. > if a <rac:RequestedAuthnContexts> element has no child <rac:RequestedAuthnContexts> elements, then the RACComparison attribute applies to the processing of the child <saml:AuthnContextClassRef> elements so I think 'all' remains relevant. This allows an SP to express simple combinations of 'this and that'. Indeed, for our use case, an SP would actually most likely just want to say 'both of unique credential and password (or alternative)' and could do this with <RequestedAuthnContexts RACComparison="all"> <samlp:AuthnContextClassRef>password</samlp:AuthnContextClassRef> <samlp:AuthnContextClassRef>unique</samlp:AuthnContextClassRef> </RequestedAuthnContexts> But, I do agree that the text of Line 131 is too constraining. is this your concern? > For those RequestedAuthnContexts that do have RequestedAuthnContexts > sub-elements, it seems that only "all" (and possible a new operator > "either") should be used. Where "all" represents AND and "either" > represents OR. > Each child RequestedAuthnContexts> element resolves to a single authn context. So, in principle, these could be combined using the full set of allowed attribute values. I think that 'exact' can serve as 'OR'? Or at least it could if we tightened up its definition to remove 'at least one' > > - I think that although the schema supports infinite nesting, the text > should reflect that a RequestedAuthnContexts element is either a > top-level element or a nested element (only one level deep). I.e., do > *not* allow the following: > > <RequestedAuthnContexts> > <RequestedAuthnContexts> > <RequestedAuthnContexts> > ... > fair enough, i'll tighten up the text about 'arbitrarily complex' > > Tom. > > P.S. it seems like introducting both RequestedAuthnContexts (with an > and/or operator) and RequestedAuthnContext (with an AC comparison; > perhaps even reusing the one from SAML Core) would make this simpler. > we looked at reusing the <samlp:RequestedAuthnContext> element but hit up against the fact that the processing rules for the existing element are defined in terms of a match with the eventual AuthnStatement. So, for instance if the Comparison attribute were set to 'exact', then the rule is that the resulting AuthnStatement MUST have an authentication context that is the exact match of one of the options - but this cant be guaranteed when combinations are made. > > -----Original Message----- > > From: Paul Madsen [mailto:paulmadsen@rogers.com] > > Sent: Friday, July 07, 2006 9:16 AM > > To: Thomas Wisniewski > > Cc: OASIS SSTC > > Subject: Re: [security-services] SAML Authn Ctx Combination Spec > > > > > > Sorry for the confusion Tom. > > > > The schema snippets I inserted in my previous message was not my > > proposal, but rather my interpretation of what you were proposing, > > (which I then tried to argue against :-) ) > > > > My actual proposal to address the issue you raised was/is as follows > > > > 1) keep schema as is in v2 (5/18/06) > > 2) relax text that limited the number of <RequestedAuthnContexts> > > elements in a message to ensure that nesting is allowed > > > > thanks > > > > Paul > > > > Thomas Wisniewski wrote: > > > > > > Paul, I agree with your sentiments. > > > > > > Perhaps I'm looking at a diff version (5/18/06), but what you are > > > proposing obviously changes the schema and the example (you > > indicated > > > that neither would change). The current spec proposes a > > single element > > > RequestedAuthnContexts that was nested whereas the changes > > you propose > > > below would indicate a list of RequestedAuthnContext > > elements inside a > > > single RequestedAuthnContexts element. So the schema would > > changes as > > > you indicated below and the example would change to > > > > > > <RequestedAuthnContexts RACComparison="all"> > > > <RequestedAuthnContext RACComparison="exact"> > > > <saml:AuthnContextClassRef...></..> > > > </RequestedAuthnContext> > > > <RequestedAuthnContext RACComparison="exact"> > > > <saml:AuthnContextClassRef...></..> > > > </RequestedAuthnContext> > > > </RequestedAuthnContexts> > > > > > > Tom. > > > > > > > -----Original Message----- > > > > From: Paul Madsen [mailto:paulmadsen@rogers.com] > > > > Sent: Friday, July 07, 2006 8:27 AM > > > > To: Thomas Wisniewski > > > > Cc: OASIS SSTC > > > > Subject: Re: [security-services] SAML Authn Ctx Combination Spec > > > > > > > > > > > > Thomas Wisniewski wrote: > > > > > > > > > > It would seem ok, but a bit awkward. > > > > > > > > > why? > > > > > > > > > > Would your example be changed to > > > > > > > > > > <RequestedAuthnContexts RACComparison="all"> > > > > > <saml:AuthnContexxtClassRef...></..> > > > > > <RequestedAuthnContexts RACComparison="exact"> > > > > > <saml:AuthnContexxtClassRef...></..> > > > > > </RequestedAuthnContexts> > > > > > </RequestedAuthnContexts> > > > > > > > > > > Is that whay you're trying to say? > > > > > > > > > the example wouldn't change. I was proposing leaving the > > schema as > > > > is, merely loosening the text that disallowed multiple > > > > <RequestedAuthnContexts> elements in a message > > > > > > > > > > Why not just have a top level (maxOccurs="1") > > > > > RequestedAuthnContext element that then defines an unlimited > > > > > number of > > > > RequestedAuthnContext > > > > > elements that have a comparison operator attribute and > > contain the > > > > > saml AuthnContextClassRef element. > > > > > > > > > So, something like > > > > > > > > <complexType name="RequestedAuthnContextsType"> > > > > <sequence> > > > > <element ref="RequestedAuthnContext" > > maxOccurs="unbounded"/> > > > > </sequence> > > > > </complexType> > > > > > > > > <complexType name="RequestedAuthnContextType"> > > > > <sequence> > > > > <element ref="saml:AuthnContextClassRef" > > > > maxOccurs="unbounded"/> > > > > </sequence> > > > > <attribute name="RACComparison" type="anyURI" use="optional"/> > > > > </complexType> > > > > > > > > we wanted the comparison operator on the top-level > > element as well. > > > > Given that, we tried to minimize the number of new elements by > > > > introducing the nesting. > > > > > > > > Additionally, the above forces an SP to insert the > > > > <RequestedAuthnContext> element even when all they want to do is > > > > give a list of <AuthnContextClassRef>s they want combined. > > > > > > > > > > Do I need to satisfy all the RequestedAuthnContext elements in > > > > > order to satisfy the RequestedAuthnContexts element? I.e., in > > > > your example > > > > > you say this is an AND -- so I assume the answer is > > yes. I.e., you > > > > > cannot express that you are requesting either AC-1 or AC-2 > > > > (exactly) > > > > > in your schema. > > > > > > > > > the 'all' on the outermost <RequestedAuthnContexts> in > > the example > > > > requires you to satisfy both. We don't have an 'either' > > but neither > > > > does core SAML. > > > > > > > > > - > > > > Paul Madsen e:paulmadsen @ ntt-at.com > > > > NTT p:613-482-0432 > > > > m:613-302-1428 > > > > aim:PaulMdsn5 > > > > web:connectid.blogspot.com > > > > > > > > > > > > ---------------------------------------------------------------------- > > > -- > > > > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: > > > 7/4/2006 > > > > > > > -- > > Paul Madsen e:paulmadsen @ ntt-at.com > > NTT p:613-482-0432 > > m:613-302-1428 > > aim:PaulMdsn5 > > web:connectid.blogspot.com > > > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006 > -- Paul Madsen e:paulmadsen @ ntt-at.com NTT p:613-482-0432 m:613-302-1428 aim:PaulMdsn5 web:connectid.blogspot.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]