IDP3 Occasionally failing to generate user attributes

Timothy Enders tenders at loyola.edu
Wed Sep 2 12:06:49 UTC 2020


>
>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.
>

Sure. The Overt Shibboleth / Azure bridge is actually a Shibboleth SP that they've configured to carry out the Azure auth for the IDP. I've got a service call open with them so we'll see what they say. Basicall, authn requests come to the Shib IDP, it shunts them off through the Overt SP, which does the call to Azure for the auth, Azure returns a yes / no, the SP sends it back to the IDP for token generation and handoff to the SP that the user was trying to log in to.

The concerning thing for me is that I don't see corresponding events in the SP log for the Bridge for these "broken" auth attempts - just in the IDP log.

>
>If the only "broken" cases are when the Validate action logs that (null) string, that probably is the only underlying issue.
>

Yup, that's the case. It's only when there's that (null) string. Everything else works fine. Also this is happening across various SPs, but Zoom was just where we noticed it since we have Zoom set up to create accounts on login, and most of our SPs have pre-populated user databases so these broken logins would just result in failure. In Zoom they create new accounts for the long alpanumeric string so they were easy to find and track.

I'll see what Overt has to say once I'm in touch with their engineers.

Thanks very much again for your help.
-Tim

Tim Enders
Senior Systems Engineer
[1518788691975_Loyola.jpg]
4501 N. Charles Street
Baltimore, MD  21210
tenders at loyola.edu<mailto:tenders at loyola.edu>
Office- 410-617-2542
Fax - 410-617-6658
www.loyola.edu
<http://www.twitter.com/LoyolaMaryland>

<http://www.twitter.com/LoyolaMaryland>

________________________________
From: users <users-bounces at shibboleth.net> on behalf of Cantor, Scott <cantor.2 at osu.edu>
Sent: Tuesday, September 1, 2020 4:43 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: IDP3 Occasionally failing to generate user attributes

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


--
For Consortium Member technical support, see https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg&data=02%7C01%7Ctenders%40loyola.edu%7C1d191dbc63ad4887c22c08d84eb7c1c6%7C30ae0a8f3cdf44fdaf34278bf639b85d%7C0%7C1%7C637345898420386814&sdata=O2x2bHiSfDp6DAo8K0i1qsJSot7u%2F4FBw%2BGBegMR0PE%3D&reserved=0
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200902/f69438cc/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-1518788691.jpg
Type: image/jpeg
Size: 8726 bytes
Desc: Outlook-1518788691.jpg
URL: <http://shibboleth.net/pipermail/users/attachments/20200902/f69438cc/attachment.jpg>


More information about the users mailing list