the burden of shibboleth

Mon, Apr 20, 2009

Back when it was first touted as the next generation access management paradigm, Shibboleth was hailed as the hero that would free electronic resource providers and consumers from the shackles of local account administration. One username/password would get you into all resources to which an institution subscribed. Turns out, the shackles were indeed removed from the suppliers but were then divvied up and redistributed among the suppliers and subscribing institutions. How can this be? A Shibboleth enabled supplier just consumes attributes and opens its digital doors in accordance with the values of those attributes. Therein lies the problem though. Most suppliers in the UK Federation just want eduPersonTargetedID (ePTID) for personalisation and maybe eduPersonScopedAffiliation or eduPersonAffiliation. They assume the Identity Provider (IdP) is working on behalf of one institution. So if you assert ePTID you get access to the resources. But what if the IdP is working on behalf of a federation of institutions? and the supplier has all the resources lumped into one access bundle? It can take up to 6 months to partition those resources based on attribute names/values.

You need to agree on an attribute to start with and that usually means asking around as I don’t think anyone has really exercised the eduPerson schema enough. Then you have to agree a value for that attribute then both sides have to go away and implement various bits of the solution. The IdP has to be capable of mapping existing attributes to the new one and the supplier has to more than likely contact their outsourced shibboleth implementation supplier for a major upgrade to the software to support resource partitioning. But this is all part of Shibboleth now. I can turn up at a supplier with a bag of attributes and I should be able to see the resources to which I am entitled. More often than not, I’ll see resources I’m not allowed to see as the supplier has never thought about using attributes in this way. A lot of to-ing and fro-ing occurs, explanations are offered, shibboleth discussed and the whole process starts again from scratch with the next supplier. Then one set of resources switches suppliers and you’re back to square one. Shibboleth is really starting to become an unbearable burden.

The vision of fine grained access to targeted resources, down to module level even, is looking more and more like an administrative nightmare. A nightmare shibboleth was designed to forgo but is in fact creating.

But why is this? Where is the bottleneck? It’s in the profile itself. It doesn’t support the use case I would like to see implemented. Why must I do the rounds of suppliers, repeating myself ad nauseam and waiting months for access to resources we pay for with no idea whether those resources will still be with that supplier in six months time? The investment in time and effort that produces access rules based on attributes is handed over, lock stock and barrel to the supplier. I invest the time, the effort, the sweat and patience into getting these rules set up but on a whim, the resource could move to a different supplier or platform and I lose everything. It’s happened and it will happen again.

There is still no answer to the loss of Athens permission sets when moving to the federation. Using these, you can set up your own access rules in minutes. You can partition resources held in Athens on a grain far finer than you’ll get in the same time in a shibboleth enabled supplier. Whereas in Athens it take minutes, in the federation it takes months.

So what’s the solution? What’s that use case I want to implement but can’t? Well, think about it for a moment. The IdP knows everything there is to know about you as an institutional user. With a little effort it can also know what you are entitled to access. There are groups of staff in the institution who set the access rules. Librarians who buy subscriptions. Lecturers who arrange access to electronic resources. They all know who should get access and who shouldn’t. For example, all students on MOD101 should get access to “MOD101 In 10 Easy Steps”. No-one else should. In a federated institution, one partner can subscribe to a resource and only they be allowed access. All these rules are in the institution. Why expend horrendous amounts of effort translating those rules into language suppliers speak, hoping that the resource will stay with that supplier for the length of its subscription? Why not, instead, codify those rules on the institional side? In the IdP.

When I go to a supplier’s website and try to gain access to a protected resource, I am sent back to my IdP to authenticate. What if the IdP knew what I was trying to access and compared that with known rules? Why bother sending an AuthenticationStatement back to the Service Provider if I’m not allowed to get access to that resource in the first place? An institution and its federated partners would be free to subscribe to electronic resources in the knowledge that informing the IdP of the access rules will guarantee that only those users and groups of users who are allowed access will get access. In a timely manner. Unlike the six months it can take at the moment.

And therein lies the problem. Shibboleth does not support this use case. It has the concept of a providerId which covers a supplier, not the groupings of eBooks within. That’s fine if you’re subscribing at the supplier level but of no pratical use if you want to partition eBook access from one supplier. Instead, you must jump through the administrative hoops placed in your way by Shibboleth.

By adding this functionality institutions can take control over their subscription rules. All their access criteria are held in one place, within the institution, rather than across multiple supplier sites, beholden to external politics and market forces. Externalising these rules is an enormous burden on institutions who want to go that next step down the federated highway. Resource partitioning is painful and it always will be as suppliers have more than just shibboleth to support.

Institutions should be able to manage their own access rules within the confines of their identity space. Shibboleth needs a makeover.

comments powered by Disqus