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
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
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.