Remap existing attribute at IdP for a particular SP?

[Peter Schober]

* David Bantz <dabantz at alaska.edu> [2012-08-23 20:06]:
> I'm missing something and would appreciate elucidation.  If the SP
> wants the attribute to be named ePPN in the IdP response (as I
> understood from the original post), how is it that creating a new
> attribute enables you to send ePPN with the different value.  I have
> a similar situation, but reckoned I needed to call the unchanging
> numeric ePPN-like attribute something locally defined, like
> uanumericPN.  Maybe it's the phrase "on the wire" in Rob Ansaldo's
> post that I don't understand.

That was me saying "on the wire" because on the wire (i.e., inside the
attribute statement of the SAML assertion issued by the IdP) the
attribute name is "urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
a.k.a. friendlyName="eduPersonPrincipalName". In both cases.

Internal to your IdP the new attribute would be known as uanumericPN
(or whatever), so you can differentiate those two different attribute
defintions within your policy, esp. the attribute filter, where you
would selectively release "eppn" or "uanumericPN" depending on SP
requirements.

So you define two attributes with unique ids (as always), with
different sourceAttributeIDs (e.g. one your netid; the other something
else like Rob's employeeNumber example), but you encode to the same
SAML attribute -- and so will both be seen as ePPNs by any SPs
(because they are, "on the wire").
-peter