Attribute mapping on new SP3 install

Peter Schober peter.schober at univie.ac.at
Wed May 15 06:24:41 EDT 2019


* HCUK eLearning <daveperryatwork at gmail.com> [2019-05-15 11:37]:
> The userPrincipalName comes from an AD attribute and includes the
> domain/scope already. [...]
> 
> I can't see how to define a scope as a parameter (I tried scope="@
> hull-college.ac.uk" as an attribute of the definition, to no avail).

There's no need to do any of that. If the attribute comes "scoped"
from LDAP and you put it into a "Prescoped" attribute definition
you're done! There's nothing else needed, otherwise the docs would be
mentioning it.

If that doesn't help you fix this: Could you just post the data
verbatim? What's the value, how does your IDP existing config look
like? Alternatively: How does it look on the wire (IDP or SP debug
log)? That way we can eliminate the IDP as the source of the problem.

> A post I found via google led me to attribute-policy on the SP side, so I
> modified the scope on on ScopedRules there to be @hull-college.ac.uk, and
> restarted the SP. But it still didn't work.

You shouldn't need to do that, either. An IDP should only release
attributes with scopes that its own metadata whilelists. I.e., the
metadata the SP has about the IDP should contain all scopes the IDP
intends to assert attributes in.

So I think it comes down to the IDP asserting the wrong -- either
factually wrong or simply not part of its published metadata, yet --
scopes. An SP should not need to change its policies for any of this:
Those are generic rules that help prevent impersonation by rogue IDPs
and should always remain in place. 

-peter


More information about the users mailing list