An assumed understanding of SAML

My favorite session during our Access Lab 2020 conference was an admirably candid account of a release that included a change to the login journey on a publisher’s website. This caused more disruption than the publisher was comfortable with. One of the key lessons they shared was not to make assumptions about anything: your users, your customers, the validity of your ideas, or the place of your product within the scholarly ecosystem.

The open nature of this account chimed for me with an excellent book by Matthew Syed called Black Box Thinking. It’s about learning from failure without apportioning blame, and how learning from failure can drive innovation – because “we cannot grow unless we are prepared to learn from our mistakes”.

One theme of the book talks about the risks associated with “habits of assumed understanding”. Our service desk often deals with support tickets where assumptions about how access management should work are firmly entrenched. Here is one which crops up regularly.

SAML is an open standard, therefore I know how SAML works

We get this from publisher development teams. A lot. This is not to say they’re at fault for this view. There are a number of documentation articles that support that view. However, it often overlooks grey areas in the SAML specification. The Shibboleth open-source implementation of SAML was specified for this reason – to bring order and predictability to a secure method of exchanging authentication and authorization data. SAML needed operating instructions for true interoperability.

It has been my ‘privilege’ to read tortuous threads between publisher technical specialists and institutional network technicians trying to build a peer-to-peer SAML connection. Because that’s how SAML works, isn’t it? Or worse – a hapless librarian is put in the middle of the conversation. Significant effort is often spent trying to reach agreement on (say) the format of a NameID attribute to uniquely identify users whilst protecting privacy. And when this gets too difficult, they default to using an email address. Hmmm.

You want us to do that NOW?

The OpenAthens team have been resetting the expectations of publisher technical teams for years. Unfortunately, we sometimes discover these mismatched expectations rather late in the day. Sometimes that day is the publisher’s release day – which can make it a surprise with consequences.

Here are some of the issues we’ve seen in the last 12 – 18 months:

• A publisher joins an identity federation having previously relied on IP recognition as its primary access route. But they did not update their subscription records with their customers’ federation IDs. Users can’t login.
• A federated resource is upgraded and replaced – but the new resource is not registered in the federation(s) where its predecessor was available. Users can’t login.
• A federated resource changes its WAYFless link syntax without advising their customers. Links registered in link resolvers and library management systems instantly become obsolete. Users can’t login.

At OpenAthens we are acutely aware that the login process is the final piece in a complex publishing workflow. We don’t want to distract a publisher’s development team from that important work. But we do ask you to keep us updated with your development timetables, and to make sure our service desk’s testing of your product’s login journey has a place on your project plan.

So keep talking to us. Without that dialogue, you could be building a beautiful palace on a sun-dappled island with no means of visiting it.

Nobody’s perfect

Some reading this might reasonably ask “and what about OpenAthens – surely you make incorrect assumptions too?” Yes, we do, and in the interests of fairness here is a recent one:

The COVID-19 situation caused us to review how we manage our administrator accounts, as almost all our customers now required access from home. Our development team worked quickly to build and release a change to the login process for administrators. We were pleased to get this enhancement out quickly to our customers. But everyone assumed someone else had briefed our service desk on how it worked and what questions they might expect to see. Oops.

I’ll close with a quote from Matthew Syed: “Learn from the mistakes of others. You can’t live long enough to make them all yourself.”