alternate attribute names

[Klingenstein, Nate]

Baron,


All the SAML names on the wire are totally independent from those used internally by the IdP.  Maybe you could try following your traditional strategy and be sure to set friendlyName="mail" (or whatever else they want) on the relevant attribute encoder.


Take care,

Nate.

________________________________
From: users <users-bounces at shibboleth.net> on behalf of Baron Fujimoto <baron at hawaii.edu>
Sent: Monday, June 18, 2018 2:25:10 PM
To: Shib Users
Subject: alternate attribute names

We are working with an SP (ArcGIS) who in unable to properly handle 'mail'
as a potentially multivalued attibute. Normally we would offer an
alternate attribute we have defined with id=uhEmail which we guarantee to
to be single-valued and encode with the same OID as the sandard mail
attribute where this is an issue. However, this SP also insists that this
attribute they require be named 'mail'.

Is there a way to remap a defined attribute's name (id) in an attribute
filter policy, or conditionally specify its source attribute in an
attribute definition based on the requesting entityID in the attribute
resolver? How can we release our single-valued uhEmail attribute to this
SP as 'mail' without disrupting our existing definition or release of
'mail' for other SPs already in use? What's the recommended way to handle
this?

--
Baron Fujimoto <baron at hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180618/2f07e5a4/attachment.html>