Attribute filter policy conditional on existence of attribute?

[Baron Fujimoto]

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.

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.


On Fri, Nov 18, 2022 at 7:48 AM Peter Schober via users <
users at shibboleth.net> wrote:

> * Baron Fujimoto via users <users at shibboleth.net> [2022-11-18 18:03]:
> > 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="saml2.name
> > ">urn:oid:0.9.2342.19200300.100.1.1</prop>.
>
> OK, though I don't follow why those users would need to get a separate
> IDP-internal attribute "altUid" assigned only so that you later run
> into the current problem of which attribute you'd release as "uid" on
> the wire.
> I.e., it seems to me you only really have (and need, with the IDP) one
> "uid" attribute, that's simply sourced from different data for
> different populations. Phrased that way this is an extremely common
> issue, e.g. when populating the "mail" attribute for students
> vs. faculty/staff. Only one "mail" attribute in the IDP just the same.
>
> > 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.
>
> Good to know, because that's where I would have done this were this my
> own IDP and so what my next suggestion would have been. ;)
>
> I think you may be mistaken about the efficiency since you said you'd
> needed to "synthesize an altUid" for that part of the user population
> anyway (which would be about the same as populating one "uid"
> attribute from two difference source attribute, depending on the user
> population)?
> But maybe you meant you're doing this (the "synthesizing of altUid")
> outside of the IDP and not at run-time, everytime.
>
> -peter
> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>


-- 
Baron Fujimoto <baron at hawaii.edu> ::: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum descendus pantorum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20221118/04b4f3ea/attachment.htm>