Develop pathway for ILLiad stub accounts to complete registration when RemoteAuth (particularly EZproxy) is in use.
Desired behavior: Patrons authenticated via RemoteAuth (EZproxy) who begin but do not complete registration can subsequently return to registration with their data populated from the latest info in the UserValidation table.
We use RemoteAuth for patrons to authenticate via EZproxy, and change implemented in order to preserve user PINs during the ILLiad 9.0 upgrade. We also do a daily upload to the UserValidation table that includes just those patrons who are eligible for ILL service. This table populates the NewAuthRegistration form so they can successfully submit registration and access ILLiad.
When users authenticate via RemoteAuth before they have been added to UserValidation, as there's no data for them in UserValidation yet, the registration form fields are blank (we intentionally prevent users from editing these fields). They cannot submit their registration, but ILLiad creates a User stub account for them with Cleared=New, which sends them back to the registration form each time they login until they've successfully submitted it.. On subsequent login attempts, even after being added to UserValidation, because the User stub account now exists, the registration form instead pulls in data from the blank stub account. Patrons remain stuck, unable to complete registration.
We are advocating for a solution that addresses this blank registration form trap. This may take the form of the Registration form always pulling in data from UserValidation, even if there is a user stub account. Alternatively, all stub accounts with only a username and Cleared=New could be automatically purged, which would force NewAuthRegistration to check UserValidation. There may be other alternatives.
I heard that there will be better SAML support in an upcoming ILLiad release. However, we do not use SAML authentication for our EZproxy setup. Instead we use a combination of CGI and ticket authentication, which passes patrons to our BiblioCommons catalog to login, then BiblioCommons returns a ticket and that essentially provides an SSO experience for our patrons using our catalog and all EZproxy-authenticated resources. So our library would benefit from a solution that also accounts for CGI/ticket authentication in EZproxy.