alternate attribute names

[Greg Haverkamp]

>
> s 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?


I haven't decided if it's better or worse, but I've lately started using
activation conditions for these requests.  (Historically, I just created
new attributes.)

https://wiki.shibboleth.net/confluence/display/IDP30/ActivationConditions

We just go ahead and release by ID, so the poorly implemented SP's get our
other attributes, too.  I gather you could script that out in an Attribute
Filter Policy if you wanted, but that seems pretty messy.

But in our email case:
  <resolver:AttributeDefinition xmlns="urn:mace:shibboleth:2.0:resolver:ad"
id="email" xsi:type="Simple" sourceAttributeID="mail">
    <resolver:Dependency ref="myLDAP"/>
    <resolver:AttributeEncoder
xmlns="urn:mace:shibboleth:2.0:attribute:encoder" xsi:type="SAML1String"
name="urn:mace:dir:attribute-def:mail"/>
    <resolver:AttributeEncoder
xmlns="urn:mace:shibboleth:2.0:attribute:encoder" xsi:type="SAML2String"
name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail"/>
    <resolver:AttributeEncoder
xmlns="urn:mace:shibboleth:2.0:attribute:encoder" xsi:type="SAML2String"
name="email_address" friendlyName="email_address"
activationConditionRef="CventComPredicate"/>
  </resolver:AttributeDefinition>

Cvent just gets urn:oid:0.9.2342.19200300.100.1.3 and email_address (and a
handful of others I grumbled about for a bit.  Cvent was one of the more
frustrating integrations I've done in a while.)

Greg



On Mon, Jun 18, 2018 at 2:26 PM Baron Fujimoto <baron at hawaii.edu> wrote:

> 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/3beaf704/attachment.html>