IDP3 Occasionally failing to generate user attributes

[Cantor, Scott]

On 9/1/20, 1:57 PM, "users on behalf of Timothy Enders" <users-bounces at shibboleth.net on behalf of tenders at loyola.edu> wrote:

>    These two auths both contain the long alphanumeric string that begins with "AAdzZWN" which is what Zoom ends up
> using as the user ID of the new account it creates. I was assuming (forgive me because I don't know much about
> NameID) that this was the transient NameID value that our IDP generated for that auth. Is that correct?

That would be up to your logging configuration but I assume so. Values that long suggest you've configured it to produce cryptogprahically managed stateless transient IDs, which is certainly not required in most deployments, simple memory-backed GUIDs will do. Still won't be anything Zoom can use. It's not getting something it expects obviously.

If you want to block transactions that don't conform to an expected profile to avoid problems and trap errors before they reach Zoom, you can certainly do that, but it won't stop them, just catch them earlier.

> And then it continues on like that. It seems like these "failures" are compressed into spats of a few minutes or so at a
> time, spaced out over the day.

I just happened to notice something in the log that combined with the use of External basically says that external code has a bug. What all that is about is beyond me, it's not our code.

If it's still breaking Zoom even when the user identity is passed in fine, the resolver is still mis-configured in some other way and failing to produce whatever it's supposed to. If the only "broken" cases are when the Validate action logs that (null) string, that probably is the only underlying issue.

-- Scott