This topic is for discussion of "Seamless Access and Federated Authentication: next steps." To go back to this session in Sched, click here.
Happy to continue the discussion here…
Links shared during the live Q+A:
https://seamlessaccess.org/stakeholders/for-service-providers/
https://wiki.geant.org/display/AARC/Libraries+walk-in-user+pilot
https://www.worldcat.org/webservices/registry/Institutions
https://spaces.at.internet2.edu/display/CAR/CAR%3A+Consent-informed+Attribute+Release+system
1 Like
Here’s a resource that came up in discussion today: “Frequently Asked Questions – for libraries and library service providers” https://aarc-project.eu/libraries/faq/
Also, for a bit more of a fun look at the FIM workflow: “Federated Authentication Roleplay” https://aarc-project.eu/wp-content/uploads/2017/04/AARClibraries-roleplay.pdf
1 Like
Re. what you say about attribute bundles in the presentation Heather, and their incorporation into a license, so that everyone could be clear that :
‘This is this is what your service provider is allowed to request from my identity provider. And on the campus identity provider side, this is a really easy way to say-- rather than to go assuming you’re in a campus library that doesn’t control the IDP, to go to your identity provider and say, this is it, just tag this particular service provider with authentication only, and that’s all they’re getting.’
If more providers sign up to this, it would help with all the red tape and compliance procedures we are embroiled in with the infosec manager, university solicitor and compliance team (data protection risk assessments) that we are now being asked to complete - for every renewal of a subscription - in our post GDPR UK university.
As things are, the increased risk of lapsed subscriptions as renewals get held up has forced us to develop attribute bundles ourselves, as a library in conjunction with our IdP: green, orange and red based on the minimum levels of personal information required by each SP (which can be so grouped), which compliance / legal can quickly look at and approve, and these should go into operation with our IdP at some point this year.
I wonder if other institutions are already doing the same thing?
It is really to be welcomed if SPs / publishers take more advantage of the capabilities of SAML and have more of a hand in asserting the terms of their licenses using the right technical means to do so, as a collaborative partner, rather than leaving the institution and IdP to do that work alone. It might not be a fair assumption that SPs don’t ‘pull their weight’ so to speak, but in the absence of dialogue it is how it feels at times (please anyone from an SP side, jump in as there is surely a lot I’m not aware of - none of this is easy).
Another very welcome development along these lines would be attribute bundles or common names that identify the common forms of partner affiliation, especially transnational or TNE partner affiliations. A good start might be to simply recognise the alum@university attribute value as a means to block out Alumni users where needed. These could really reduce the burden on infosec-conscious IT teams, who are under a lot of pressure, in managing the legacy of very unwieldy and sometimes chaotic active directories (which is the other way to ensure the license is complied with - like sorting the old files on an ancient PC used by thousands of people!) . This sort of work took up up to a fourth of my work time last year, and my institution’s case, all for a fairly small number of users.
As it is, I think it’s a good question whether all partners are using SAML to its full capacity. Instances like alumni users who are asserted via the IdP that they are ‘alum@university’ but still being allowed access to big providers who rigorously state in the license that alumni aren’t permitted, regardless (!), suggests not; I think it can be seen in SAML traces which attributes are actually ‘consumed’ too, though I’m not an expert in parsing those. In something like the REFeds metadata explorer tool, it can be seen that many (most?) SPs don’t mark up their attributes as “required”, if they’re included at all, as the schema would allow. However concerned we might about privacy, quite a high number of players don’t seem to pay attention to any of the attributes released apart from the one that says they’re from the institution and using its IdP - very similar to IP authentication, then. Using a very sharp tool as if it were a blunt club, perhaps.
If SeamlessAccess.org is the vehicle that motivates and focuses a real, widespread effort to become more conversant, literate and productive with the SAML standard, which all of us can collaborate over, then it’s to be welcomed, I believe.
1 Like