Shibboleth Developers

["Scott Cantor" <>]

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

> :-) 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.

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

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)

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