IDP3 Occasionally failing to generate user attributes

[Timothy Enders]

Scott:

Thanks SO much.

For the record, we are using the Overt Software Shibboleth Bridge product for this. It's basically a separate SP that does the Azure (or ADFS, in the past) part of the process for us. I'll check in the SP logs for that, and then with Overt and see if they can be of help if I can't get anywhere on my own.

However:
These (at least some of the ones I've checked) do appear to be actual users who did have a successful auth through Azure. In that case, is this somehow still Azure returning a "null" value (that's actually that string) every so often when someone logs in?

I assume that the further error about the Attribute Definition script not running correctly is maybe caused by the fact that the IDP can't look up the user in LDAP at all, instead of a communication issue with LDAP. Does that make any sense?

Thanks again for your help.

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 11:22 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: IDP3 Occasionally failing to generate user attributes

a) Your authentication implementation is broken and is returning some kind of string value of "(null)" or some such instead of signaling failure. You can't possibly have that kind of log output without it doing something very, very wrong in the External bridge code.

The code absolutely checks for null there, which means the value isn't in fact null, it's actually got to be that string. That should never happen.

b) Your attribute logic is reacting to errors (or suppressing them) in such a way as to allow the absence of any information to be successful and not raise fatal errors, and having done that, you are deciding that issuing empty assertions is an acceptable outcome.

There are error handling options all over the system to influence all of that.

(a) is honestly of much greater concern. There's no way that should be happening and that isn't the IdP doing that, it's the other side of that callout.

-- 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%7C1ad8257f9dd64cb1b09508d84e8b4742%7C30ae0a8f3cdf44fdaf34278bf639b85d%7C0%7C0%7C637345707400837424&sdata=jM2I6Szo5BgKSQAKeHACeRf3%2Bs7hzNPzcvm%2BCvW6Edw%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/20200901/a13adc60/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/20200901/a13adc60/attachment.jpg>