[Eril-l] SSO/SAML and attributes vendors want but maybe don't need? data grab?

[Electronic Resources in Libraries discussion list]

Many library workers do not understand that it is the library/university that controls the SSO attribute set that is released to the vendor. Our Cornell Library default SSO attribute set are these, none of which include name:

EduPersonAffiliation
EduPersonOrgDN
EduPersonEntitlement
EduPersonPrimaryaffiliation
EduPersonScopedAffiliation
transitID

If vendor says they need personal data we push back and ask them why they need it for the service to function. Ideally these negotiations happen before the license is signed.  We have a good working relationship with campus identity management unit. We did a presentation last spring that describes some of our efforts to protect readers.

Raub, Emma, Jesse Koennecke, and Adam Chandler. “Cookies & PII: Baking: Values into Library Privacy.” Electronic Resources & Libraries 2025, Austin, TX, March 24, 2025. https://hdl.handle.net/1813/116786.

I’m interested in hearing from others about their efforts to resist vendor moves to cash in on surveillance capitalism.

Adam

Adam Chandler
Director, Automation, Assessment, and Post-Cataloging Services
Library Technical Services
Cornell University Library


From: Eril-l <eril-l-bounces at lists.eril-l.org> On Behalf Of Electronic Resources in Libraries discussion list via Eril-l
Sent: Monday, November 10, 2025 10:37 AM
To: ERIL-L listserv <eril-l at lists.eril-l.org>
Subject: [Eril-l] SSO/SAML and attributes vendors want but maybe don't need? data grab?

Hi, all.

I'm still trying to understand what the vendor movements away from IP authentication and especially for off-campus users mean, and have gotten some help from Gemini.
UPEI belongs to the Canadian Access Federation (CAF), and we use MS Azure as our SSO system for our IdP.

As I understand it, all our vendors need to know about our users is the same as what they knew about them when using ezproxy for off-campus access, which is that this user has authenticated as a UPEI valid user.

According to a sample test I ran, our IdP doesn't send out any specific attributes, but it does tell the service provider that this person is a valid UPEI person and provides a persistent "name" code that is anonymized.

Below is how Gemini explained it:
So, while the service provider learned nothing about your personal identity (not your name, role, or email), it learned everything it needs to know about your institutional context.
By accepting this SAML assertion, the service provider is implicitly saying: "I have received a digitally signed, unforgeable message from the official authentication authority for UPEI, and that authority vouches for the fact that they have successfully authenticated one of their valid users."
This is the core of federated identity: authentication is handled entirely by the home institution. The service provider doesn't need to know who you are, only that UPEI has confirmed you are a legitimate member of its community.

However, almost all of the library providers I have dealt with so far to configure SSO authentication have required us to take extra steps to provide them with more specific "attributes" like "eduPersonScopedAffiliation", and sometimes even PII (personally identifiable information) including first and last name and email address.

The vendor could use that persistent "pseudonym" code allow this specific UPEI user to create whatever kind of personalized account services (eg saving searches) that vendor's platform has.

So it seems to my suspicious mind that our vendors are taking advantage of the move towards SSO to get from us far more user-specific data than they actually need to provide the services we are paying for. They didn't have a problem for decades with providing their content to users who offered nothing more than our Ezproxy server's IP address. But suddenly they "need" PII to provide that same access?

Is anyone/any library organization pushing back on this?  What can we librarians do?  Do we have to work with our IT depts to convince them to get their SAML/SSO providers (like Microsoft for Azure) to include more anonymizing options so we can send fake names and email addresses when our vendors demand them?

I would guess that the European institutions have already been able to solve this, given the GDPR (which we in North America badly need too).  How did you do it? What did you say to the vendors? Are there any "magic words" to get them to admit they don't need all those attributes they are demanding from us?

Melissa Belvadi
Collections Librarian
University of Prince Edward Island
mbelvadi at upei.ca<mailto:mbelvadi at upei.ca>  902-566-0581
ORCID iD: 0000-0002-4433-0189
my public calendar<https://outlook.office365.com/owa/calendar/0fbab27c909e4493be65313bd66d66b6@upei.ca/5fa60af92c6d451c9ddf90c0bb11e00f15552192987609852692/calendar.html>
My pronouns are ಅವರು/ಅವರನ್ನು
My emails are sent during the hours that I work and I understand that you will respond during the hours that you work.

Make an appointment: Use YouCanBookMe https://mbelvadi.youcanbook.me/
or for other MS365 / Outlook users, including UPEI people:
[cid:image001.png at 01DC5233.B6B5A6C0]<https://outlook.office.com/bookwithme/user/0fbab27c909e4493be65313bd66d66b6@upei.ca?anonymous&ismsaljsauthenabled&ep=bwmEmailSignature>
Book time to meet with me<https://outlook.office.com/bookwithme/user/0fbab27c909e4493be65313bd66d66b6@upei.ca?anonymous&ismsaljsauthenabled&ep=bwmEmailSignature>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eril-l.org/pipermail/eril-l-eril-l.org/attachments/20251110/56809055/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 528 bytes
Desc: image001.png
URL: <http://lists.eril-l.org/pipermail/eril-l-eril-l.org/attachments/20251110/56809055/attachment.png>