<div dir="ltr">In this case, the attrFoo and attrBar are two variants of a uid (e.g. altUid and uid). For somewhat byzantine reasons, we have a set of users who are assigned non-standard uids, so we must synthesize an altUid for them. Since both variants are nominally uids, they are both defined in the transcoders with <prop key="<a href="http://saml2.name" target="_blank">saml2.name</a>">urn:oid:0.9.2342.19200300.100.1.1</prop>.<div><br></div><div>If I release both uid and altUid, they get merged into one of the attributes (I don't know if which one is order dependent) as a multivalued attribute: e.g.:</div><div><br></div><div>        <saml2:Attribute FriendlyName="altUid" Name="urn:oid:0.9.2342.19200300.100.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><br>            <saml2:AttributeValue>altUid</saml2:AttributeValue><br>            <saml2:AttributeValue>normalUid</saml2:AttributeValue><br>        </saml2:Attribute><br><div><br></div><div>Unfortunately, the SP can only use one attribute key on their end for its business logic, so it is looking for "urn:oid:0.9.2342.19200300.100.1.1". When it encounters the multivalued attribute in the response, it catenates the values, and they don't have a good means to undo that on their end. The problem is uid should always exist, so this leads to the catenation issue for the SP that requires the altUid. So I don't know if that is a good reason, but that's what led me down this path.</div><div><br></div><div>I think I'd rather not do it in the resolver because the proportion of cases we need the altUid is relatively very small, and it seems inefficient to have make the conditional determination every time we need to resolve the uid? Plus, it just seems cleaner imo, to confine the exception to the one place where it would be needed.</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 17, 2022 at 10:56 PM Peter Schober via users <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">* Baron Fujimoto via users <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>> [2022-11-18 02:42]:<br>
> I'd like to define an AttributeFilterPolicy that conditionally releases one<br>
> of two attributes depending on whether one of the two exists or not. In<br>
> pseudocode, essentially:<br>
> <br>
> If ( defined attrFoo ) {<br>
>     permit attrFoo<br>
> }<br>
> else {<br>
>     permit attrBar<br>
> }<br>
<br>
You positively need to prevent that both attributes are released in<br>
case both have values (if that what you mean with "exists")?<br>
If so, is there a good reason for that? ;)<br>
If not you'd simply release both attributes and the IDP would take<br>
care of not sending any that don't have any values, which seems to<br>
come close to your requirement, maybe sufficiently close.<br>
<br>
Also note that scripting can also be used in the filter, AFAIR, though<br>
it's more often used in the resolver.<br>
<br>
-peter<br>
-- <br>
For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</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><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><font face="arial, sans-serif">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 descendus pantorum</font></div></div>