<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">s there a way to remap a defined attribute's name (id) in an attribute<br>filter policy, or conditionally specify its source attribute in an<br>attribute definition based on the requesting entityID in the attribute<br>resolver? How can we release our single-valued uhEmail attribute to this<br>SP as 'mail' without disrupting our existing definition or release of<br>'mail' for other SPs already in use? What's the recommended way to handle<br>this?</blockquote><div><br></div><div>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.)</div><div><br></div><div><a href="https://wiki.shibboleth.net/confluence/display/IDP30/ActivationConditions">https://wiki.shibboleth.net/confluence/display/IDP30/ActivationConditions</a><br></div><div><br></div><div>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.</div><div><br></div><div>But in our email case:<br><div>  <resolver:AttributeDefinition xmlns="urn:mace:shibboleth:2.0:resolver:ad" id="email" xsi:type="Simple" sourceAttributeID="mail"></div><div>    <resolver:Dependency ref="myLDAP"/></div><div>    <resolver:AttributeEncoder xmlns="urn:mace:shibboleth:2.0:attribute:encoder" xsi:type="SAML1String" name="urn:mace:dir:attribute-def:mail"/></div><div>    <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"/></div><div>    <resolver:AttributeEncoder xmlns="urn:mace:shibboleth:2.0:attribute:encoder" xsi:type="SAML2String" name="email_address" friendlyName="email_address" activationConditionRef="CventComPredicate"/></div><div>  </resolver:AttributeDefinition></div></div><div><br></div><div>Cvent just gets <span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">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.)</span></div><div><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Greg</span></div><div><br></div><div> </div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 18, 2018 at 2:26 PM Baron Fujimoto <<a href="mailto:baron@hawaii.edu">baron@hawaii.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We are working with an SP (ArcGIS) who in unable to properly handle 'mail'<br>
as a potentially multivalued attibute. Normally we would offer an<br>
alternate attribute we have defined with id=uhEmail which we guarantee to<br>
to be single-valued and encode with the same OID as the sandard mail<br>
attribute where this is an issue. However, this SP also insists that this<br>
attribute they require be named 'mail'.<br>
<br>
Is there a way to remap a defined attribute's name (id) in an attribute<br>
filter policy, or conditionally specify its source attribute in an<br>
attribute definition based on the requesting entityID in the attribute<br>
resolver? How can we release our single-valued uhEmail attribute to this<br>
SP as 'mail' without disrupting our existing definition or release of<br>
'mail' for other SPs already in use? What's the recommended way to handle<br>
this?<br>
<br>
-- <br>
Baron Fujimoto <<a href="mailto:baron@hawaii.edu" target="_blank">baron@hawaii.edu</a>> :: UH Information Technology Services<br>
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>