Shibboleth Developers

["Oleksandr Otenko" <>]

Scott Cantor wrote:

> > Can you explain this more? Why are you saying that checks against the 
> > scopes means that too much trust is placed in the identity provider?
>
>
> The identity provider was trusted to use the proper XML syntax for the
> attribute. If the syntax includes a Scope attribute, then the additional
> checking based on metadata Domain and AAP Scope elements was applied. If no
> Scope attribute is included, then the attribute is considered unscoped. This
> allows an IdP to send a malformed value inside the XML and bypass the scope
> checking. There's more to it, but it relates to how the final serialized
> string is constructed for scoped attributes.
>
> In retrospect, it was probably a mistake to try and use an XML syntax to
> separate the scope from the value, but I really needed it as a sanity check
> that the code could deal with XML structured values in the future.

Aha.... so.... I thought you were trying to forbid values of kind 
"a@b@c"

OK, so what does the improvement mean - that "c" in "a@b@c" will be 
treated as a scope domain, if the attribute is unscoped (that's what I 
thought Shib was doing), or that it will be thrown away, if scope is 
required, but not present in the XML?


Also, does the improvement affect the text representation of the 
(un)scoped attributes in the HTTP headers? (our software relies on the 
fact the scope is present after "@"; and if scope is absent, we use the 
Origin domain name)



> > :-) It reads to me that you don't want to let the identity provider to 
> > be able to specify the scope domain.
>
>
> Incorrect. We just don't want the trigger for "scope checking" to be the
> IdP's syntax, it needs to be known out of band for each attribute. Part of
> the definition, essentially.

ok, so the AAP has a "scope must be present" flag, or something to that 
effect?


> > ...or you want more flexible rules? 
> > Hmmm.. the latter means you need a proper Role/Attribute Assignment 
> > Policy. Using regular expressions as the means of checking the validity 
> > of role/attribute assignments is ...ermmmm....lame? :-)
>
>
> I don't know exactly what you mean by "role/attribute assignment policy".
> Scoping is a way of constraining things like roles to a qualifier,
> essentially. You could use regexp to do scope filtering, but that's not what
> I'm doing here.

BTW, you have many qualifiers (uri prepended to the attribute value, 
scope domain,...), which, combined together, simply define the meaning 
of the value; and could be replaced by one unique identifier.


> The point is the concept of filtering attributes at all presumes less trust
> in the IdP than the code had. Otherwise, you may as well do no filtering and
> just trust the IdP to send only reasonable and appropriate values (in which
> case you can, just plug in an AAP that doesn't filter).
>
>
> > > In addition, the default value filtering rule supplied for
> > > the eduPersonPrincipalName attribute was too lenient and should
> > > have been used to protect against an attempt to embed a scope
> > > inside the value string improperly.
> >
> > Does the last sentence imply this is a value syntax validation?
>
>
> Yes. It's to protect from an IdP inserting a "pre-serialized" scoped value
> in the text node so that it gets exported as is to the application without
> going through the filter properly.
>
>
> > How does this protect from scope spoofing? Looks like you don't allow 
> > any scope, rather than restrict the set of scopes?
>
>
> The Value rule applies only to the string inside the text node. The Scope is
> in a separate attribute. The serializer combines them afterward with a
> separator.
>
>
> > So you don't trust the Origin to provide the Target with the correct 
> > attributes after all? Or you want to throw away malformed attributes?
>
>
> More the latter. A scoped attribute without a Scope is malformed. But
> there's trust and there's trust. If you're claiming that the IdP should be
> trusted with no caveats or limitations, then either:
>
> - you're arguing the concept of filtering is wrong and unneeded (in which
> case you can make that case)
> - you personally don't think it's needed (in which case you can remove all
> the rules or use a plugin that supports none)

:-) I simply assumed that the Target used "@domain" from the value, if 
the scope XML attribute was not present. Of course, you may need to 
restrict the scope of attributes presented by the IdP.


Regards,

Sassa

> But if we distribute the software and claim it does certain kinds of
> filtering based on centralized and local policy, then it needs to do it
> properly.
>
> -- Scott