Justin Newcomer (Rochester Institute of Technology) · 3:00–4:00 PM · Cook · Gatherings (Sierra) · Wednesday, April 15
Speaker: Justin Newcomer
An informal gathering led by Justin Newcomer (Rochester Institute of Technology) about his experience implementing SAML SSO for Sierra staff and patron authentication. As one of the few sites actively using it, Justin walked through the setup, limitations, and pain points at RIT. The session evolved into a broader conversation about MFA policies, shared accounts, identity provider options, cyber insurance implications, and the prospect of Keycloak unifying identity across all Innovative products.
RIT uses Shibboleth as their university-wide identity provider with separate SAML configurations for patron authentication and staff authentication, each using different match points. They previously used external LDAP authentication for patrons before switching to SAML.
They use username (uid) as the matching attribute—chosen because it didn’t require special permissions from the IdP team. SSO IDs can be changed on the fly; Justin swaps his SSO ID to a test account to impersonate and debug.
When the Sierra desktop client launches with SSO enabled, a browser window pops up offering two choices: SAML login or legacy Sierra password. Edge works best; Firefox can be flaky. On Chrome, Windows credentials pass through to the browser and Duo MFA decisions happen automatically.
Even with SAML fully configured, the legacy Sierra password login cannot be disabled—both options always appear on the login page. Justin has raised this issue repeatedly. The login page is Sierra-controlled, so libraries cannot modify the scripting or remove the legacy option.
Justin plans to submit an IdeaLab request after the conference to require MFA, not just allow it. Previous requests were “loose with words”—they demanded MFA support but not MFA as a requirement. He encouraged the room to help word-smith the request “with lawyers in mind.”
Several Sierra-adjacent applications still require legacy password authentication:
| Application | SSO Status | Notes |
|---|---|---|
| Decision Center | Legacy password only | — |
| Circa | Legacy password only | No longer sold, but RIT uses it daily |
| Circulation overrides | Legacy password only | Supervisor override pop-up at circ desks uses legacy credentials |
| Innovative/Vega mobile worklists app | No | Legacy only; a roadmap slide suggested SSO support may be coming |
Justin mentioned he might vibe-code a Circa replacement using Shibboleth/PHP for authentication to work around the SSO gap.
Students get SSO access through their university accounts. Justin sets a random password they never receive—SSO is their only way in. If a student needs Decision Center or Circa, they require the legacy password as well.
Students self-enroll for Duo MFA automatically. Justin noted: “I had confusion trying to explain how to enroll, then they told me it’s just automatic. I stopped trying to explain it and we haven’t had problems since.”
Patron authentication matches on a different attribute (University ID in patron records). RIT disabled the patron choice between SAML and barcode/PIN, forcing SAML-only since all patrons have RIT accounts. The one or two theoretical community users with expired accounts were told to get an RIT account.
Forcing SAML for patrons eliminates password reset support entirely. As Justin put it: “It’s Central IT’s problem.”
Attendees noted that any shared account can move a library into a more expensive cyber-insurance tier, even if the account’s permissions are heavily restricted. The cheapest rate typically requires every user to be a single signer with no shared service accounts — which has pushed some libraries to phase out shared accounts for programs and provision per-person accounts instead.
Justin’s advice: “If you have Google, Google ‘Google SAML.’ If you have Microsoft, Azure that up.” The setup is self-service—you can configure it in test mode through the Sierra admin web app without affecting production. The metadata exchange is straightforward: match the SSO ID field to whatever attribute your IdP sends.
One attendee asked about allowing patrons to choose their own IdP—sign in with Google, Apple, Meta, and so on—the way consumer sites work. Justin noted that SAML is designed for defined groups; OAuth might be a better fit for “bring your own” patron authentication. The idea has major potential for public libraries, but it raises support questions: password resets and account recovery would go to Apple or Google, not the library.
One attendee described staff traveling to 9 different locations who need different context logins for each location’s stack groups. They stood up their own IdP to create 9 separate entries, spent 3 months working with their IT department and the city, and ultimately concluded “we can’t do that” with current Sierra.
Possible approaches included multiple accounts with the same password but different usernames, or dummy Google nonprofit accounts per location. Justin candidly acknowledged: “I only have bad ideas about how to solve this.”
An attendee asked about automatic provisioning—mapping LDAP groups to Sierra permission groups. This does not exist currently: no SCIM, no automatic role-based provisioning. Justin manages approximately 80–90 staff accounts manually, cloning permissions from existing accounts.
“Takes longer to close out the ticket with proper change controls than to actually click ‘copy from other supervisor.’” Justin also prefers keeping control in-house rather than letting central IT touch Sierra groups: “They touched groups I had specific notes saying do not touch.”
An attendee (possibly from the Innovative/engineering side) confirmed that Vega currently runs through Keycloak for identity management.
There are plans to make Keycloak a shared service across all products—pushing it down to Polaris and across to Sierra. If this happens, IdeaLab requests for SSO improvements would benefit all products simultaneously rather than requiring incremental changes in each module.
The session included a candid survey of how different libraries handle multi-factor authentication:
| Library | IdP | MFA Method | Notes |
|---|---|---|---|
| RIT (Justin) | Shibboleth | Duo (YubiKey + web auth) | Disabled SMS, disabled push, using verified push (type 3 numbers). No phone-call MFA. |
| Attendee (Google shop) | Google Workspace (free nonprofit) | YubiKey + phone | Must manually assign YubiKeys per account—no bulk provisioning on free tier. YubiKeys also used for physical door access (NFC). |
| Attendee (Microsoft shop) | Azure AD / Entra ID | Microsoft Authenticator app | 4 out of 75 staff requested hardware tokens (Token2). SMS turned off. |
| Another attendee | Microsoft | MS Authenticator | Conditional access: no MFA required on library network. Off-network requires MFA every time. |
RIT requires 16 characters, set once, never rotated unless the password is detected on a breach list (following the Microsoft standard). One attendee uses Spanning (a Google Workspace backup tool) with dark web monitoring for compromised credentials—it has flagged a match only once in four years.
Justin does not check Sierra passwords against breach lists—it is unclear how that would work given Sierra’s password infrastructure. The room’s general consensus: long passwords + MFA + no rotation is the modern standard.
Justin expressed interest in passwordless authentication but remains cautious. His concern: a YubiKey alone (something you have) without a password means anyone who knows the username and has the key gets everything.
One attendee described a setup where the YubiKey requires a PIN to unlock, preserving the two-factor model (something you know + something you have). Justin noted he is attending a Google conference next week to learn more about passwordless at enterprise scale, but added: “I’m not going to be the first person on campus to push for it.”
