IDP3 Occasionally failing to generate user attributes

[Timothy Enders]

Hi everyone:

Forgive the novel I am about to write, but I have an oddball situation that I could really use some extra eyes on.

We have an implementation of IDP v3 that we use as part of our enterprise SSO architecture. When a user signs in to a Shibboleth protected resource, the IDP uses a bridge to do authentication against Azure, and then uses an LDAP connection (round robin to our on-prem AD DCs) to do attribute generation after a successful auth.

We have been having an issue lately where when a user signs in to Zoom (one of the apps that uses Shibboleth), instead of signing the user into their own Zoom account, it will create them a new account with a gibberish name and sign them in to that. Normally, Zoom should be looking at the Employee ID number attribute (and failing back to the email address attribute if that one's missing) that we send to either match the user to an existing Zoom account or create a new one for them. Instead, it appears that sometimes Zoom is creating accounts for people based of the SAML NameID, which Shibboleth is sending as a Transient (randomly generated value). When I look at the Zoom SAML logs for these instances, Zoom has received a valid SAML token that contains no attributes and has a Transient NameID and so it has created an account with that NameID for the name.

This seems to happen in spats of a ton of instances all at once. For example, in one minute yesterday (8/31/20, 07:36) there were 90 of these accounts created. In each instance where this happens, if I look at the IDP Process log on the IDP server, there's an entry like this:

----------
2020-08-31 07:36:57,854 - INFO [net.shibboleth.idp.authn.impl.ValidateExternalAuthentication:147] - Profile Action ValidateExternalAuthentication: External authentication succeeded for user: (null)
2020-08-31 07:36:57,886 - ERROR [net.shibboleth.idp.profile.impl.ResolveAttributes:314] - Profile Action ResolveAttributes: Error resolving attributes
net.shibboleth.idp.attribute.resolver.ResolutionException: Attribute Definition 'institutionID':Script did not run successfully
at net.shibboleth.idp.attribute.resolver.ad.impl.ScriptedAttributeDefinition$AttributeDefinitionScriptEvaluator.execute(ScriptedAttributeDefinition.java:228)
Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:657)
2020-08-31 07:36:57,901 - INFO [Shibboleth-Audit.SSO:275] - 20200831T113657Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|a-327a26fb10e0f0a-3g842hg5b15a9bi|https://loyola.zoom.us|http://shibboleth.net/ns/profiles/saml2/sso/browser|https://shibprodapp.loyola.edu/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_6b04475da047ed6ca73babbc6d4d9f8b|(null)|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport||AAdzZWNyZXQxvGzllP1nvqweGpg/pLsjKC3cldHFGs2LanhcDqIUorKf/caErkJ8/fdJxp1fupq+FHcYPzbSdPxqdrAYUcf1FHywL6/N/3GG19VOGrdSY8Id4fh2cUAZEHoFhQ==|_cfb376e0414280e14de0d9d4a2d36729|
----------

It looks to me from this log that the IDP may be having difficulty making the LDAPS connection to the DC to read the user's attributes after a successful auth, and then is building an auth token without any attributes and sending it. Does that sound right? I don't know enough about the Shibboleth specific error messages to know what it means when it gives the line about:

Attribute Definition 'institutionID':Script did not run successfully

But it seems that it's caused when the IDP can't read the LDAP attributes for the logged in user.

I *think* that I need to go track down why the IDP is failing it's check of the LDAP every so often, but I wanted to run it by the list to see if anyone has seen anything similar in the past, or has any ideas. There doesn't seem to be any consistency as to when it does this vs working properly - there will be a large spate of failures like this over the course of a minute or two, and then things will go right back to normal, it reads attributes and generates the tokens normally, and users log in successfully.

Thoughts?

Thank you!
-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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200901/a1e0a723/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/a1e0a723/attachment.jpg>