<div dir="ltr">Currently, we only have one attribute source (LDAP) aside from any special cases we synthesize within the IdP based on some other LDAP attribute(s). I don't think we're prepared to try to set up an additional attribute source for this small subset of users. As alluded to, there are some kind of byzantine internal reasons why they exist this way, and mucking around with that drags in other parts of the organization, lifecycle, and other data management issues for these users. We have a separate project to migrate some core identity management processes to Midpoint, and maybe we can find a better way to handle these cases then.<div><br></div><div>I could well be mistaken about the efficiency (it's on my todo list to investigate if it's possible to conditionally defined the altUid in the resolver via activation condition, or something like that, if that's possible. But I don't know if that buys anything really if you have to evaluate the condition anyway). But at least it leaves the definition for the normal uid clean for the 99.9+% of the cases.<br><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 18, 2022 at 7:48 AM Peter Schober via users <<a href="mailto:users@shibboleth.net">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 18:03]:<br>
> altUid and uid). For somewhat byzantine reasons, we have a set of users who<br>
> are assigned non-standard uids, so we must synthesize an altUid for them.<br>
> Since both variants are nominally uids, they are both defined in the<br>
> transcoders with <prop key="<a href="http://saml2.name" rel="noreferrer" target="_blank">saml2.name</a><br>
> ">urn:oid:0.9.2342.19200300.100.1.1</prop>.<br>
<br>
OK, though I don't follow why those users would need to get a separate<br>
IDP-internal attribute "altUid" assigned only so that you later run<br>
into the current problem of which attribute you'd release as "uid" on<br>
the wire.<br>
I.e., it seems to me you only really have (and need, with the IDP) one<br>
"uid" attribute, that's simply sourced from different data for<br>
different populations. Phrased that way this is an extremely common<br>
issue, e.g. when populating the "mail" attribute for students<br>
vs. faculty/staff. Only one "mail" attribute in the IDP just the same.<br>
<br>
> I think I'd rather not do it in the resolver because the proportion<br>
> of cases we need the altUid is relatively very small, and it seems<br>
> inefficient to have make the conditional determination every time we<br>
> need to resolve the uid? Plus, it just seems cleaner imo, to confine<br>
> the exception to the one place where it would be needed.<br>
<br>
Good to know, because that's where I would have done this were this my<br>
own IDP and so what my next suggestion would have been. ;)<br>
<br>
I think you may be mistaken about the efficiency since you said you'd<br>
needed to "synthesize an altUid" for that part of the user population<br>
anyway (which would be about the same as populating one "uid"<br>
attribute from two difference source attribute, depending on the user<br>
population)?<br>
But maybe you meant you're doing this (the "synthesizing of altUid")<br>
outside of the IDP and not at run-time, everytime.<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" class="gmail_signature"><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>