Attribute filter policy conditional on existence of attribute?

Peter Schober peter.schober at univie.ac.at
Fri Nov 18 17:48:18 UTC 2022


* 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


More information about the users mailing list