Remap existing attribute at IdP for a particular SP?
dabantz at alaska.edu
Thu Aug 23 14:05:40 EDT 2012
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.
UA OIT IAM
On Thu, 23 Aug 2012, at 07:48 , Rob Ansaldo <rlansaldo at amherst.edu> wrote:
> On Aug 23, 2012, at 10:34 AM, Peter Schober <peter.schober at univie.ac.at> wrote:
>> * Rob Ansaldo <rlansaldo at amherst.edu> [2012-08-23 15:22]:
>>> We have a commercial SP that insists that our IdP assert an
>>> eduPersonPrincipalName for each of our users and that this value be
>>> a unique identifier for each user that will not change over
>>> time. Our eppn is the user's netid, which can change over time (name
>>> changes, class year change, etc). Our employeeNumber attribute does
>>> not change over time and we would like to provide this attribute for
>>> eppn, but just for this one SP.
>> Rob Ansaldo <rlansaldo at amherst.edu> [2012-08-23 15:22]:
>> Usually you would create a new attribute definition in your IdP, pull
>> in employeeNumber as value and encode it as eduPersonPrincipalName on
>> the wire.
>> Then only release this new attribute to this specific SP, not your
>> original one with netid values.
> Works perfectly! A little messy to have a "special" attribute for one SP, but I can live with it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users