Associating SP users with specific IdPs

[Peter Schober]

* Robert Lowe <robertmlowe at rmlowe.com> [2013-03-21 18:59]:
> Thanks for the detailed response Scott.
> 
> > Should one require that the IdPs send scoped attributes and then
> > > somehow filter out attributes that don't have the correct scope?
> >
> > The SP filters them automatically provided the metadata allows it to do so.
> 
> What exactly in the metadata would enable that?

<shibmd:Scope regexp="false">example.org</shibmd:Scope>

See also attribute-policy.xml in the SP's config directory.

> > You could also rely on the  NameID construct and its qualifiers and do
> > filtering based on that, along with having flexibility in how you serialize
> > the NameID structure into an identifier to consume.
> 
> Other than scope, what qualifiers of NameID would be relevant here?

NameIDs are not scoped (in the sense that eduPersonScopedAffiliation
is), they are 3-tuples: IdP identifier, SP identifiers, subject
identifier. The wiki has lots more info on NameIdentifiers.

> > > Or should the IdPs send unscoped attributes and the SP somehow
> > > add the appropriate scope before passing the attribute to the
> > > application?
> >
> > It does not do that, though of course an application could.
> 
> Couldn't a Template AttributeResolver do that, or at least produce
> something that *resembles* a scoped attribute?

The above was about the *SP* making a scoped attribut out of an
unscoped one (i.e., after the fact of recieving an unscoped one from
the IdP). The AttributeResolver of the IdP can of course create scoped
variants from unscoped ones, which is very useful and a sensible thing
to do. E.g. I don't store scoped identifiers in my data source (as the
scope is implicit frmo the data source and would hence be the same for
all identifiers) and qualify them before sending them out.
But the above was about the inverse of that, which is not as useful
and so not common at all, to my knowledge.
-peter