Cadmore media player playing video Seamless Access and Federated Authentication: next steps
Video Player
Accessibility
Using forms mode, you can utilize keyboard shortcuts to make usability more efficient.
Space bar will play and pause the video. Pressing escape will close all displays and pressing it again will jump to the end of the player.
You can press A to open the Keyboard Shortcut Dialog which also provides an audio description of the player and all of its features.
Language
1x
Play Speed
Adjust Volume
Transcript
Search
Result Count
of
Click to jump to result
Search
Re-center
Segments
Result Count
of
Click to jump to result
Search
Name:
Seamless Access and Federated Authentication: next steps
Description:
Seamless Access and Federated Authentication: next steps
Thumbnail URL:
https://cadmoremediastorage.blob.core.windows.net/dcddde5b-cef9-45dd-a932-cd546c84760b/videoscrubberimages/Scrubber_1.jpg?sv=2019-02-02&sr=c&sig=4jG%2B%2B3RC9twBX6ZpVSn9RqZ5SxVCCz1WDFO1vDF4e%2FA%3D&st=2024-11-22T18%3A21%3A48Z&se=2024-11-22T22%3A26%3A48Z&sp=r
Duration:
T00H33M30S
Embed URL:
https://stream.cadmore.media/player/dcddde5b-cef9-45dd-a932-cd546c84760b
Content URL:
https://cadmoreoriginalmedia.blob.core.windows.net/dcddde5b-cef9-45dd-a932-cd546c84760b/11 - Seamless Access and Federated Authentication next steps.mov?sv=2019-02-02&sr=c&sig=vCuBuiQCxOIzaNywt4SNTLogepK8QsVmgfldKHU3JL8%3D&st=2024-11-22T18%3A21%3A48Z&se=2024-11-22T20%3A26%3A48Z&sp=r
Upload Date:
2023-02-13T00:00:00.0000000
Transcript:
Language: EN.
Segment:0 .
[MUSIC PLAYING]
JASON GRIFFEY: Hi, everyone. My name is Jason Griffey. I am the Director of Strategic Initiatives at NISO and the Chair and Director of the NISO Plus conference. But today, I am here in the form of a moderator of the SeamlessAccess and Federated Authentication Next Steps session with Heather Flanagan. I am here also because I am part of the SeamlessAccess efforts with NISO and I may chime in, but I think this is primarily going to be Heather's show.
JASON GRIFFEY: Heather Flanagan is the program director of the SeamlessAccess.org project and is the principal at Spherical Cow Consulting. She is definitely the person that knows the most about SeamlessAccess writ large. And I'm really pleased that she's able to be here with us today to talk about how the project is going and what the next stages of the project may look like. So welcome, Heather.
JASON GRIFFEY: And thank you for being here.
HEATHER FLANAGAN: Thank you, Jason. So at this point, I'm going to guess that most of you have heard about SeamlessAccess, and you've almost certainly been exposed to federated authentication. The last 12 months have been what I fondly call a character building experience. And as such, a lot of our expectations about how people access information, a lot of what has worked in the past hasn't been working very well.
HEATHER FLANAGAN: And when SeamlessAccess kicked off right after the Resource Access in the 21st Century project, we thought we would have something of a gradual on ramp of getting service providers, getting librarians, getting identity providers all conversant with what we wanted to have happen to improve the federated authentication experience, slow on ramp. That's not what happened.
HEATHER FLANAGAN: So it's been a banner year in terms of having to try and do so many different things. And I'm going to go over some of that. I will do a little bit of introduction, just to make sure that we're all on the same page with regards to why SeamlessAccess exists, its timelines, things like that, and also talk a little bit about some of the working groups, some of the challenges that we have, and what's coming next for us.
HEATHER FLANAGAN: So we'll start with-- OK so let's get on the same page, why does SeamlessAccess exist? Why are we here? We're here to improve the remote access scenarios. A lot of what has been in this space in the past has been confusing for the user. It's been inconsistent. It's been just all over the map in terms of how well it works, how well it's presented, the user experience.
HEATHER FLANAGAN: We want to improve usability. We do want to make sure that we're enabling a secure solution for single sign-on. We know that personalization is important and also particular when it comes to protecting privacy. So we want to make sure that we're not enabling anything that's going to break that. And whatever we can do to enhance user privacy mechanisms without overtly getting in the users way are pretty important to us.
HEATHER FLANAGAN: So what's wrong with what we had, the IP authentication? Surely that was working great because it was just the server. Now we want to talk seamless, all you have to do is be on the right network and poof there you are. Well, that's actually less secure than federated authentication. You have spoofing possibilities.
HEATHER FLANAGAN: You have-- it's not actually that difficult to start rewriting URLs to get people to look like they're coming from or going to different locations. I know that if you're an institution using IP authentication that you have experienced or you will pretty soon the situation of one compromised account can result in blocked access for your entire institution because there's no way to track down who has been compromised.
HEATHER FLANAGAN: I worked at a large R1 institution and that even happened there. And it was a really big problem. And trying to manage IP addresses, especially in this day and age, is non-trivial in and of itself, trying to keep up with the address ranges when you don't necessarily know at the library level what IP blocks have been assigned or reassigned or changed. It's a very difficult management process.
HEATHER FLANAGAN: So I mentioned RA21, the Resource Access in the 21st Century project. That initiated in 2016 to just explore the challenges of remote access. It included stakeholders from several communities-- publishing, library, software developers, and identity communities. We had over 60 different organizations represented and offering their input or their review.
HEATHER FLANAGAN: And it didn't start with a well, yes, of course we're going to do SAML federation. That's not actually-- it was-- it was even higher level than that of OK what out here is going to work for us? And over the course of that project, it was federated identity management seemed like the most promising solution that would give us the access, would give us the scalability, the privacy, and the security that we needed.
HEATHER FLANAGAN: But to get there from here, as I mentioned before, the user experience was appalling. It was really bad, I've been working in the federated identity space for about 20 years. And it's a community that I hold very near and dear to my heart. And they are smart, smart people. But they are not good at making things usable for the end user. That's not how they think. And so this was an area of significant gap.
HEATHER FLANAGAN: And when RA21 came along with all the resources from all these different stakeholders to help resolve this, it was a huge thing for the entire world of federated identity. So at the end of the project, which was in April of 2019, a NISO recommended practice was published. We had over 200 comments that helped identify areas where the people wished that the recommendation had gone into a little bit more detail.
HEATHER FLANAGAN: And it confirmed the idea of you know what, this is recommending a central service that helps enable all these moving parts. Let's go ahead and try to do that. And that's what SeamlessAccess-- that's where SeamlessAccess actually came from. So what is SeamlessAccess now? It's currently four organizations.
HEATHER FLANAGAN: NISO, which I hope you're familiar with given where you are and what you're doing right this moment; the International Association of Scientific Technical and Medical Publishing; Internet 2 that hosts the InCommon Identity Federation; and Géant, which is a collaboration of national research and education networks in Europe and responsible for a lot of outreach and grant funding to identity federations around the world.
HEATHER FLANAGAN: So that's like the core of the SeamlessAccess and where resources come from. But when you actually start breaking that up into, OK, how does it all fit together? There is the governance committee, which has representatives from a variety of stakeholder groups. We have an implementation team, including the program director which is me, publisher outreach a lovely woman by the name of Heather Steans.
HEATHER FLANAGAN: We have technical support from SUNET, the Swedish Federation with funding from Géant. We have library outreach, spearheaded by Jason himself. And we also have a user experience team. This is partially volunteer. It is partially in kind funded. And we're getting a lot done, though there's no one who's working on this full time, in and of themselves.
HEATHER FLANAGAN: So a lot of moving parts that are coming together pretty well, I think, to offer a solid service. There is an outreach committee. This is almost entirely volunteers. And their main mission is to help bridge the gap of education and communication between SeamlessAccess and the library and publishing community. There is a Contract Language working group.
HEATHER FLANAGAN: We're going to talk a little bit more about that later. And we're also considering a new working group on the where are you from entry disambiguation, oh, a lot of interesting words and we'll get to that shortly as well. So great, that's a lot of moving parts. What's the timeline look like here? So the piloting phase was RA21.
HEATHER FLANAGAN: And that is done. The SeamlessAccess beta phase is what we're in now. And there's been some question as to, well, what does beta even mean in this context? From an operational standpoint, the service itself is designed as a high availability service. It is very well architected, hosted by strong content delivery network with a 24/7 network operating center monitoring the service and staying on top of all the changes.
HEATHER FLANAGAN: We have change control processes. We have a status.io basically monitoring this. And anyone can sign up to receive notifications for when we're expecting to schedule outages, things like that. So from that operational sense, it is a production service. But from a feature sense, that's where we're still doing a bit of experimentation to try and understand where the guidelines in RA21 were not clear enough, were not sufficient, or perhaps when hitting the reality of so many different service providers and the service providers requirements, do they actually fully meet the need.
HEATHER FLANAGAN: And that's what we are working on now. I think that the broad outlines of what we want in terms of having a standard call to action button, what's in that button, where it's placed on the page, all of that is reasonably solid. But we're getting into some of the gory details now about what service providers really need to do to do this well. And I think we'll see that conversation continue at least through June and possibly past that.
HEATHER FLANAGAN: I'm hoping, this is a personal hope, that we'll always see incremental improvements, which in a way makes it hard to say when are you no longer a beta, because any time you say, "and we're done," you've become out of date. And that's not what I think we want to have happen. So OK, that sounds fantastic. But what did we say the users were going to actually experience here?
HEATHER FLANAGAN: Why are we thinking this is going to be such an awesome thing? So we're trying to-- SeamlessAccess from a purely technical perspective, we're focused on one aspect of the federated identity management workflow, just one. And that's the, where are you from, getting the user to the correct identity provider.
HEATHER FLANAGAN: That's actually all that we do, again, from a technical perspective. We do not do anything-- we do not do the authentication. We do not control attributes. All we're doing is getting the user to the identity provider and storing whatever choice of identity provider they've made in their browser. It's not stored anywhere else. The usernames aren't stored.
HEATHER FLANAGAN: Email addresses aren't stored, just that choice. It used to be that every time a user went to a service provider, they had yet another way of trying to find their identity provider. And they may have had more than one click. The experience was just all over the map. And that's not what we want to see, right? So we want to say, OK, you're maybe at one institution and you're going to see yourself going to CERN to do some research or maybe to Elsevier to actually get some journal articles.
HEATHER FLANAGAN: You know, it's having to log in every time, having to find your identity provider every time. That's sort of the definition of inefficiency. And it doesn't need to be that way. So instead when we're talking about SeamlessAccess, each of these service providers will instead display a button, a call to action button. And that call to action button just reads what's in browser local storage, which is the institution that you chose.
HEATHER FLANAGAN: And it will then let you just skip the whole where are you from component. Now there's, of course, some caveats here. If for some reason you are a member of several institutions, you might want to change this. There is guidelines for that, how to do that, when it's appropriate for the service provider's perspective, what language they need to use, all of that's in there.
HEATHER FLANAGAN: But at the heart of it, it's stop making people try and find how do they log in. OK, so where are we today? That's our current-- I just showed you the model of what things are supposed to look like. So while we are focused on the where are you from component, we're actually-- that's such a central part of the federated identity workflow that we seem to be a very good place in the ecosystem to say, you know what, all right, we from a technical perspective are not responsible for attribute release.
HEATHER FLANAGAN: But if you're using our service, that is probably something you're interested in controlling. So let's talk about that. Let's get all the right stakeholders in a room and say, what's the most responsible way to manage this consistently and cleanly? And so first we had a working group called Entity Categories and Attribute Bundles. And the goal of that working group was to define a way for service providers rather than all being inconsistent in terms of what they're asking for, some asking for email address, some asking for name, some saying please don't send me anything at all, trying to narrow that down into just a few options such that you could take these options and say, oh, for example, putting them in a contract with a publisher to say this is what you're allowed to ask for.
HEATHER FLANAGAN: 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.
HEATHER FLANAGAN: And you don't have to be unique for every single service provider contract that's coming in, narrowed it down to just a few things. So we came up with three entity categories. The first one was authentication only. And this is an entity-- this was a very interesting entity category. This is one that says don't send any data, just don't, no attributes, none.
HEATHER FLANAGAN: We don't want them. All we want to know is, did the user authenticate? This was requested by several members of the publishing community who were working with identity providers that were sending more data than the publisher wanted. Now I know that some librarians have indicated this is very difficult to believe. But a lot of publishers are very anxious about being liable for the data that they hold, if they've received it without explicit permission.
HEATHER FLANAGAN: I think we can look over to Europe and thank the folks who wrote the GDPR for a little bit of that healthy concern. But not every institution falls under GDPR. And some institutions have said, we'd rather just share information and enable all the things. And this was making the publishers, again, very uncomfortable.
HEATHER FLANAGAN: So authentication only was the first entity category that we proposed. The second one is called anonymous authorization, where there is a bit more information shared. That information is, was the user able to authenticate, yes or no; and are they authorized to access the resource by using something like an attribute called common-lib-terms? Nothing more specific about the user than that, was the user able to authenticate?
HEATHER FLANAGAN: Are they authorized to use the resource? And that's all. The third entity category is pseudonymous authorization. And you can probably see the path here. This has a little bit more information that the user is able to authenticate that they are authorized to access the resource. And there is a targeted pseudonymous identifier so that while the service provider may not know exactly who the user is, they do know it's the same user each time, and so they can actually start to offer some more personalized services as appropriate.
HEATHER FLANAGAN: These entity categories-- the SeamlessAccess can propose these, but we cannot implement these. For that to happen, that was sent over to the federation operator community, which actually controls the metadata for all the federations, and what they'll support, what goes in them. That group is REFEDS, stands for the R and E Federations.
HEATHER FLANAGAN: And their steering committee-- this went out for a public consultation. We tried to make that public consultation as broad as possible announcing it through NISO, announcing it through REFEDS, announcing it as broadly as we possibly could to get input. We did get a lot of feedback. That has been incorporated. And the steering committee of REFEDS is in the process of voting on whether to approve and publish these entity categories.
HEATHER FLANAGAN: In fact-- my goodness look at the time, by the time that this session is actually presented at NISO, I may be writing in chat telling you whether or not the steering committee approved any of these entity categories, because they are voting on them individually. So they may not choose authentication only and approve an anonymous authorization and pseudonymous authorization. They may approve all three.
HEATHER FLANAGAN: Stay tuned, we'll know more shortly. So the next working group-- and this one is active-- is the Contract Language Working Group. And the contracts, as I understand it-- and I'm going to turn to Jason shortly to keep me honest on all of this-- the contracts between publishers and libraries right now are a little on the inconsistent and perhaps archaic side, where they don't take into account the federated identity workflows.
HEATHER FLANAGAN: And sometimes they actually even explicitly say, no, you can't do that. So what this working group is trying to do is come up with a common template developed by librarian representatives, developed by publisher representatives that actually talk about how are you going to handle federated identity. What do attribute release policies look like from a contract perspective?
HEATHER FLANAGAN: How do you ensure compliance in your contract?
JASON GRIFFEY: What we have found, Heather, is that in many cases, the contract language that's in place right now only refers to network level access all based on IP, right, rather than being more directed towards individual authentication actions as the reason people are allowed to access something. And so there does need to be some fairly significant work done in making federated authentication language more commonly, both, understood and used in contracts between libraries and service providers.
JASON GRIFFEY: And so that's definitely a big piece of what we're working on.
HEATHER FLANAGAN: So my understanding is that these are templates. We are not lawyers.
JASON GRIFFEY: No.
HEATHER FLANAGAN: You will need to-- you know, when these templates are available, you will want to take them to your finance group, to your legal counsel, and make sure that they fit what's needed in your jurisdiction. But at least it gives you a better place to start than what's available now, which is not much.
JASON GRIFFEY: Yeah. What we are attempting to put together is sort of a tool kit for people to be able to work their way through what do you need, what do you want, what are the desired outcomes, and to be able to select language that would get you there from the perspective of data sharing and everything. So it's going to be, hopefully, a little bit modular and a little bit choose your own adventure for contract language.
HEATHER FLANAGAN: Great. Thank you. All right, there's a working group that we're considering. I currently have a note out to my advisory committee asking for their thoughts on this. And this is an interesting problem. And this is not a new problem. But now that we're seeing so much more heavy use of federated identity and seamless access, which is consolidating so much information into a more standardized where are you from service, we are seeing this issue where a user going through the wave service may find something that looks like an identical identity provider.
HEATHER FLANAGAN: This is an example. Boston College is one of at least about 150 that I know of. From the end-user's perspective, how are they-- what's different? What's going on here? Do they pick one? Do they pick the other? Does it matter?
HEATHER FLANAGAN: Well, that's an interesting problem for them, isn't it? So what's happening here is an institution may have two separate identity providers registered with the same display name, which is what you just saw. But the entity ID, the URL that that name points to may be different. Now there's reasons for that. Several of you may be from-- one example, but not limited to, is if an institution has a Shibboleth identity provider run by their campus ID system and an OpenAthens identity provider service run by their library.
HEATHER FLANAGAN: That's what's happened at Boston College. They have one Boston College-- BC.eud pointing to Shib and the other one pointing to OpenAthens and the user can't tell what is what. Solving this isn't as easy as you might think. let's say OK, well, let's go ahead and change the display name. Change it how? What if things are actually-- in some where are you from services where the alphabetization matters?
HEATHER FLANAGAN: OK, well, then just add something to the end. Oh, now you go back to that call to action button where you only have so much real estate, so it may still look like Boston College dot, dot, dot. How is the user supposed to tell? It's tricky. It's complicated. It's both political and technical in terms of what can we recommend to resolve this.
HEATHER FLANAGAN: And rather than come up with relatively arbitrary decision, we'd like to get the right stakeholders in the room to talk through the actual use cases where this is happening, the different possibilities for solutions because it may turn out to be that what works for one institution may not work for another. So can we come up with a selection of solutions, something along the lines of a choose your own adventure?
HEATHER FLANAGAN: If this is your scenario, this is the best practice. If that is your scenario, that is your best practice. We will get this, I'm hoping, assuming that the advisory committee comes back to me and says, yes, this makes a lot of sense for SeamlessAccess to be in the middle of-- to have this started before the end of Q1 of this year.
HEATHER FLANAGAN: But wait, there's more. What else are we doing? We're also working directly with the integrators, the service providers, targeting in particular the advanced integrators, which are those integrators using their own API, rather than the self-contained service that we offer. And we're infinitely grateful to the advanced integrators because, as I mentioned earlier, we are a beta service, because there are some things where we need to better understand how the recommendations work when in the wild, as it were.
HEATHER FLANAGAN: When actually users who know nothing about federated identity are experiencing this, what works? What doesn't? How can we improve it? And by having the advanced integrators do things a little bit differently, we're learning a lot about what should work well for everybody, and what kind of changes we want to make, either to our service directly or to our documentation.
HEATHER FLANAGAN: Our first integrated workshop was in December. And our next one is at the end of March. So I expect we'll be talking quite a bit more about things like AB testing, which if you have any user experience experience in your background, you'll know that AB testing offering that is it this, does this make sense, how would you users click on that versus a different experience and where are users clicking on that, and getting that kind of metrics to let us know what's working and what isn't.
HEATHER FLANAGAN: Well, I'm sure you all now very fascinated and you want to know, how can I be involved in this? How can I get the latest and greatest news on what's happening with SeamlessAccess? Well, OK, so if you're in the library, and this is all kind of new to you, then you need to actually be making a couple of plans. You do need to talk to your campus IT a bit, see is SAML supported?
HEATHER FLANAGAN: Do you have privacy policies and attribute release policies that you need to work in? There are different vended solutions that could help you out with this. So exploring those a little bit, and just getting involved in conversations. There is a group that I would highly recommend if you're somewhat new to this space called the Federated Identity Management for Libraries, FIM4L, that is by librarians, for librarians talking entirely about federated identity and what they see as best practice in this space.
HEATHER FLANAGAN: OK, but let's say you are an identity provider, how do you get involved, and what do you need to do? Supporting entity categories would be a really big deal in terms of helping, not just SeamlessAccess but some of the other work that's out there. If you have any researchers or people doing research on your campus, you will find there's an entity category that focuses on that.
HEATHER FLANAGAN: If you have students or faculty that ever need to get to scholarly content, oh, there's the three entity categories we just talked about, you might want to consider supporting if they're approved. You also should go ahead and reach out to your campus librarians, because they have a lot of needs in this space. And maybe you don't have the same language to talk about that.
HEATHER FLANAGAN: But now's the time to really focus on building that bridge. They are going to be one of the biggest users of federated single sign-on services outside of your campus. And so their use cases are one that you have to become intimately familiar with. And service providers, for those publishers and other folks-- because this isn't just about publishers, you know. Any one that's offering federated identity services can be using the SeamlessAccess work.
HEATHER FLANAGAN: I strongly recommend you go to our website and start looking at the documentation that we have available. It's of course, available to anybody. But for service providers in particular, this is going to answer a lot of your questions about the gory, gory details of size of button, placement of button, language in the button, language around the button. It's like a prepositional phase, what can you do with the button-- by it, for it, around it, through it, under it, over it, all of it, that's in our documentation site.
HEATHER FLANAGAN: And if you just think that's all well and good, but that's perhaps a little bit more than you're up for, you can also just sign up for our monthly email. There's a link on the website to get there from here. Or if you're really interested in a particular working group that I've discussed, drop a note to contact@seamlessaccess.org and we'll see what we can do. And with that, thank you all very much for your time today.
HEATHER FLANAGAN: And I'm looking forward to the Q&A section that comes next.
JASON GRIFFEY: Thank you very much, Heather. That was great. Thank you, everyone. If you do have any questions, get those ready. We will move into a Q&A session. [MUSIC PLAYING]
Segment:0 .
[MUSIC PLAYING]
JASON GRIFFEY: Hi, everyone. My name is Jason Griffey. I am the Director of Strategic Initiatives at NISO and the Chair and Director of the NISO Plus conference. But today, I am here in the form of a moderator of the SeamlessAccess and Federated Authentication Next Steps session with Heather Flanagan. I am here also because I am part of the SeamlessAccess efforts with NISO and I may chime in, but I think this is primarily going to be Heather's show.
JASON GRIFFEY: Heather Flanagan is the program director of the SeamlessAccess.org project and is the principal at Spherical Cow Consulting. She is definitely the person that knows the most about SeamlessAccess writ large. And I'm really pleased that she's able to be here with us today to talk about how the project is going and what the next stages of the project may look like. So welcome, Heather.
JASON GRIFFEY: And thank you for being here.
HEATHER FLANAGAN: Thank you, Jason. So at this point, I'm going to guess that most of you have heard about SeamlessAccess, and you've almost certainly been exposed to federated authentication. The last 12 months have been what I fondly call a character building experience. And as such, a lot of our expectations about how people access information, a lot of what has worked in the past hasn't been working very well.
HEATHER FLANAGAN: And when SeamlessAccess kicked off right after the Resource Access in the 21st Century project, we thought we would have something of a gradual on ramp of getting service providers, getting librarians, getting identity providers all conversant with what we wanted to have happen to improve the federated authentication experience, slow on ramp. That's not what happened.
HEATHER FLANAGAN: So it's been a banner year in terms of having to try and do so many different things. And I'm going to go over some of that. I will do a little bit of introduction, just to make sure that we're all on the same page with regards to why SeamlessAccess exists, its timelines, things like that, and also talk a little bit about some of the working groups, some of the challenges that we have, and what's coming next for us.
HEATHER FLANAGAN: So we'll start with-- OK so let's get on the same page, why does SeamlessAccess exist? Why are we here? We're here to improve the remote access scenarios. A lot of what has been in this space in the past has been confusing for the user. It's been inconsistent. It's been just all over the map in terms of how well it works, how well it's presented, the user experience.
HEATHER FLANAGAN: We want to improve usability. We do want to make sure that we're enabling a secure solution for single sign-on. We know that personalization is important and also particular when it comes to protecting privacy. So we want to make sure that we're not enabling anything that's going to break that. And whatever we can do to enhance user privacy mechanisms without overtly getting in the users way are pretty important to us.
HEATHER FLANAGAN: So what's wrong with what we had, the IP authentication? Surely that was working great because it was just the server. Now we want to talk seamless, all you have to do is be on the right network and poof there you are. Well, that's actually less secure than federated authentication. You have spoofing possibilities.
HEATHER FLANAGAN: You have-- it's not actually that difficult to start rewriting URLs to get people to look like they're coming from or going to different locations. I know that if you're an institution using IP authentication that you have experienced or you will pretty soon the situation of one compromised account can result in blocked access for your entire institution because there's no way to track down who has been compromised.
HEATHER FLANAGAN: I worked at a large R1 institution and that even happened there. And it was a really big problem. And trying to manage IP addresses, especially in this day and age, is non-trivial in and of itself, trying to keep up with the address ranges when you don't necessarily know at the library level what IP blocks have been assigned or reassigned or changed. It's a very difficult management process.
HEATHER FLANAGAN: So I mentioned RA21, the Resource Access in the 21st Century project. That initiated in 2016 to just explore the challenges of remote access. It included stakeholders from several communities-- publishing, library, software developers, and identity communities. We had over 60 different organizations represented and offering their input or their review.
HEATHER FLANAGAN: And it didn't start with a well, yes, of course we're going to do SAML federation. That's not actually-- it was-- it was even higher level than that of OK what out here is going to work for us? And over the course of that project, it was federated identity management seemed like the most promising solution that would give us the access, would give us the scalability, the privacy, and the security that we needed.
HEATHER FLANAGAN: But to get there from here, as I mentioned before, the user experience was appalling. It was really bad, I've been working in the federated identity space for about 20 years. And it's a community that I hold very near and dear to my heart. And they are smart, smart people. But they are not good at making things usable for the end user. That's not how they think. And so this was an area of significant gap.
HEATHER FLANAGAN: And when RA21 came along with all the resources from all these different stakeholders to help resolve this, it was a huge thing for the entire world of federated identity. So at the end of the project, which was in April of 2019, a NISO recommended practice was published. We had over 200 comments that helped identify areas where the people wished that the recommendation had gone into a little bit more detail.
HEATHER FLANAGAN: And it confirmed the idea of you know what, this is recommending a central service that helps enable all these moving parts. Let's go ahead and try to do that. And that's what SeamlessAccess-- that's where SeamlessAccess actually came from. So what is SeamlessAccess now? It's currently four organizations.
HEATHER FLANAGAN: NISO, which I hope you're familiar with given where you are and what you're doing right this moment; the International Association of Scientific Technical and Medical Publishing; Internet 2 that hosts the InCommon Identity Federation; and Géant, which is a collaboration of national research and education networks in Europe and responsible for a lot of outreach and grant funding to identity federations around the world.
HEATHER FLANAGAN: So that's like the core of the SeamlessAccess and where resources come from. But when you actually start breaking that up into, OK, how does it all fit together? There is the governance committee, which has representatives from a variety of stakeholder groups. We have an implementation team, including the program director which is me, publisher outreach a lovely woman by the name of Heather Steans.
HEATHER FLANAGAN: We have technical support from SUNET, the Swedish Federation with funding from Géant. We have library outreach, spearheaded by Jason himself. And we also have a user experience team. This is partially volunteer. It is partially in kind funded. And we're getting a lot done, though there's no one who's working on this full time, in and of themselves.
HEATHER FLANAGAN: So a lot of moving parts that are coming together pretty well, I think, to offer a solid service. There is an outreach committee. This is almost entirely volunteers. And their main mission is to help bridge the gap of education and communication between SeamlessAccess and the library and publishing community. There is a Contract Language working group.
HEATHER FLANAGAN: We're going to talk a little bit more about that later. And we're also considering a new working group on the where are you from entry disambiguation, oh, a lot of interesting words and we'll get to that shortly as well. So great, that's a lot of moving parts. What's the timeline look like here? So the piloting phase was RA21.
HEATHER FLANAGAN: And that is done. The SeamlessAccess beta phase is what we're in now. And there's been some question as to, well, what does beta even mean in this context? From an operational standpoint, the service itself is designed as a high availability service. It is very well architected, hosted by strong content delivery network with a 24/7 network operating center monitoring the service and staying on top of all the changes.
HEATHER FLANAGAN: We have change control processes. We have a status.io basically monitoring this. And anyone can sign up to receive notifications for when we're expecting to schedule outages, things like that. So from that operational sense, it is a production service. But from a feature sense, that's where we're still doing a bit of experimentation to try and understand where the guidelines in RA21 were not clear enough, were not sufficient, or perhaps when hitting the reality of so many different service providers and the service providers requirements, do they actually fully meet the need.
HEATHER FLANAGAN: And that's what we are working on now. I think that the broad outlines of what we want in terms of having a standard call to action button, what's in that button, where it's placed on the page, all of that is reasonably solid. But we're getting into some of the gory details now about what service providers really need to do to do this well. And I think we'll see that conversation continue at least through June and possibly past that.
HEATHER FLANAGAN: I'm hoping, this is a personal hope, that we'll always see incremental improvements, which in a way makes it hard to say when are you no longer a beta, because any time you say, "and we're done," you've become out of date. And that's not what I think we want to have happen. So OK, that sounds fantastic. But what did we say the users were going to actually experience here?
HEATHER FLANAGAN: Why are we thinking this is going to be such an awesome thing? So we're trying to-- SeamlessAccess from a purely technical perspective, we're focused on one aspect of the federated identity management workflow, just one. And that's the, where are you from, getting the user to the correct identity provider.
HEATHER FLANAGAN: That's actually all that we do, again, from a technical perspective. We do not do anything-- we do not do the authentication. We do not control attributes. All we're doing is getting the user to the identity provider and storing whatever choice of identity provider they've made in their browser. It's not stored anywhere else. The usernames aren't stored.
HEATHER FLANAGAN: Email addresses aren't stored, just that choice. It used to be that every time a user went to a service provider, they had yet another way of trying to find their identity provider. And they may have had more than one click. The experience was just all over the map. And that's not what we want to see, right? So we want to say, OK, you're maybe at one institution and you're going to see yourself going to CERN to do some research or maybe to Elsevier to actually get some journal articles.
HEATHER FLANAGAN: You know, it's having to log in every time, having to find your identity provider every time. That's sort of the definition of inefficiency. And it doesn't need to be that way. So instead when we're talking about SeamlessAccess, each of these service providers will instead display a button, a call to action button. And that call to action button just reads what's in browser local storage, which is the institution that you chose.
HEATHER FLANAGAN: And it will then let you just skip the whole where are you from component. Now there's, of course, some caveats here. If for some reason you are a member of several institutions, you might want to change this. There is guidelines for that, how to do that, when it's appropriate for the service provider's perspective, what language they need to use, all of that's in there.
HEATHER FLANAGAN: But at the heart of it, it's stop making people try and find how do they log in. OK, so where are we today? That's our current-- I just showed you the model of what things are supposed to look like. So while we are focused on the where are you from component, we're actually-- that's such a central part of the federated identity workflow that we seem to be a very good place in the ecosystem to say, you know what, all right, we from a technical perspective are not responsible for attribute release.
HEATHER FLANAGAN: But if you're using our service, that is probably something you're interested in controlling. So let's talk about that. Let's get all the right stakeholders in a room and say, what's the most responsible way to manage this consistently and cleanly? And so first we had a working group called Entity Categories and Attribute Bundles. And the goal of that working group was to define a way for service providers rather than all being inconsistent in terms of what they're asking for, some asking for email address, some asking for name, some saying please don't send me anything at all, trying to narrow that down into just a few options such that you could take these options and say, oh, for example, putting them in a contract with a publisher to say this is what you're allowed to ask for.
HEATHER FLANAGAN: 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.
HEATHER FLANAGAN: And you don't have to be unique for every single service provider contract that's coming in, narrowed it down to just a few things. So we came up with three entity categories. The first one was authentication only. And this is an entity-- this was a very interesting entity category. This is one that says don't send any data, just don't, no attributes, none.
HEATHER FLANAGAN: We don't want them. All we want to know is, did the user authenticate? This was requested by several members of the publishing community who were working with identity providers that were sending more data than the publisher wanted. Now I know that some librarians have indicated this is very difficult to believe. But a lot of publishers are very anxious about being liable for the data that they hold, if they've received it without explicit permission.
HEATHER FLANAGAN: I think we can look over to Europe and thank the folks who wrote the GDPR for a little bit of that healthy concern. But not every institution falls under GDPR. And some institutions have said, we'd rather just share information and enable all the things. And this was making the publishers, again, very uncomfortable.
HEATHER FLANAGAN: So authentication only was the first entity category that we proposed. The second one is called anonymous authorization, where there is a bit more information shared. That information is, was the user able to authenticate, yes or no; and are they authorized to access the resource by using something like an attribute called common-lib-terms? Nothing more specific about the user than that, was the user able to authenticate?
HEATHER FLANAGAN: Are they authorized to use the resource? And that's all. The third entity category is pseudonymous authorization. And you can probably see the path here. This has a little bit more information that the user is able to authenticate that they are authorized to access the resource. And there is a targeted pseudonymous identifier so that while the service provider may not know exactly who the user is, they do know it's the same user each time, and so they can actually start to offer some more personalized services as appropriate.
HEATHER FLANAGAN: These entity categories-- the SeamlessAccess can propose these, but we cannot implement these. For that to happen, that was sent over to the federation operator community, which actually controls the metadata for all the federations, and what they'll support, what goes in them. That group is REFEDS, stands for the R and E Federations.
HEATHER FLANAGAN: And their steering committee-- this went out for a public consultation. We tried to make that public consultation as broad as possible announcing it through NISO, announcing it through REFEDS, announcing it as broadly as we possibly could to get input. We did get a lot of feedback. That has been incorporated. And the steering committee of REFEDS is in the process of voting on whether to approve and publish these entity categories.
HEATHER FLANAGAN: In fact-- my goodness look at the time, by the time that this session is actually presented at NISO, I may be writing in chat telling you whether or not the steering committee approved any of these entity categories, because they are voting on them individually. So they may not choose authentication only and approve an anonymous authorization and pseudonymous authorization. They may approve all three.
HEATHER FLANAGAN: Stay tuned, we'll know more shortly. So the next working group-- and this one is active-- is the Contract Language Working Group. And the contracts, as I understand it-- and I'm going to turn to Jason shortly to keep me honest on all of this-- the contracts between publishers and libraries right now are a little on the inconsistent and perhaps archaic side, where they don't take into account the federated identity workflows.
HEATHER FLANAGAN: And sometimes they actually even explicitly say, no, you can't do that. So what this working group is trying to do is come up with a common template developed by librarian representatives, developed by publisher representatives that actually talk about how are you going to handle federated identity. What do attribute release policies look like from a contract perspective?
HEATHER FLANAGAN: How do you ensure compliance in your contract?
JASON GRIFFEY: What we have found, Heather, is that in many cases, the contract language that's in place right now only refers to network level access all based on IP, right, rather than being more directed towards individual authentication actions as the reason people are allowed to access something. And so there does need to be some fairly significant work done in making federated authentication language more commonly, both, understood and used in contracts between libraries and service providers.
JASON GRIFFEY: And so that's definitely a big piece of what we're working on.
HEATHER FLANAGAN: So my understanding is that these are templates. We are not lawyers.
JASON GRIFFEY: No.
HEATHER FLANAGAN: You will need to-- you know, when these templates are available, you will want to take them to your finance group, to your legal counsel, and make sure that they fit what's needed in your jurisdiction. But at least it gives you a better place to start than what's available now, which is not much.
JASON GRIFFEY: Yeah. What we are attempting to put together is sort of a tool kit for people to be able to work their way through what do you need, what do you want, what are the desired outcomes, and to be able to select language that would get you there from the perspective of data sharing and everything. So it's going to be, hopefully, a little bit modular and a little bit choose your own adventure for contract language.
HEATHER FLANAGAN: Great. Thank you. All right, there's a working group that we're considering. I currently have a note out to my advisory committee asking for their thoughts on this. And this is an interesting problem. And this is not a new problem. But now that we're seeing so much more heavy use of federated identity and seamless access, which is consolidating so much information into a more standardized where are you from service, we are seeing this issue where a user going through the wave service may find something that looks like an identical identity provider.
HEATHER FLANAGAN: This is an example. Boston College is one of at least about 150 that I know of. From the end-user's perspective, how are they-- what's different? What's going on here? Do they pick one? Do they pick the other? Does it matter?
HEATHER FLANAGAN: Well, that's an interesting problem for them, isn't it? So what's happening here is an institution may have two separate identity providers registered with the same display name, which is what you just saw. But the entity ID, the URL that that name points to may be different. Now there's reasons for that. Several of you may be from-- one example, but not limited to, is if an institution has a Shibboleth identity provider run by their campus ID system and an OpenAthens identity provider service run by their library.
HEATHER FLANAGAN: That's what's happened at Boston College. They have one Boston College-- BC.eud pointing to Shib and the other one pointing to OpenAthens and the user can't tell what is what. Solving this isn't as easy as you might think. let's say OK, well, let's go ahead and change the display name. Change it how? What if things are actually-- in some where are you from services where the alphabetization matters?
HEATHER FLANAGAN: OK, well, then just add something to the end. Oh, now you go back to that call to action button where you only have so much real estate, so it may still look like Boston College dot, dot, dot. How is the user supposed to tell? It's tricky. It's complicated. It's both political and technical in terms of what can we recommend to resolve this.
HEATHER FLANAGAN: And rather than come up with relatively arbitrary decision, we'd like to get the right stakeholders in the room to talk through the actual use cases where this is happening, the different possibilities for solutions because it may turn out to be that what works for one institution may not work for another. So can we come up with a selection of solutions, something along the lines of a choose your own adventure?
HEATHER FLANAGAN: If this is your scenario, this is the best practice. If that is your scenario, that is your best practice. We will get this, I'm hoping, assuming that the advisory committee comes back to me and says, yes, this makes a lot of sense for SeamlessAccess to be in the middle of-- to have this started before the end of Q1 of this year.
HEATHER FLANAGAN: But wait, there's more. What else are we doing? We're also working directly with the integrators, the service providers, targeting in particular the advanced integrators, which are those integrators using their own API, rather than the self-contained service that we offer. And we're infinitely grateful to the advanced integrators because, as I mentioned earlier, we are a beta service, because there are some things where we need to better understand how the recommendations work when in the wild, as it were.
HEATHER FLANAGAN: When actually users who know nothing about federated identity are experiencing this, what works? What doesn't? How can we improve it? And by having the advanced integrators do things a little bit differently, we're learning a lot about what should work well for everybody, and what kind of changes we want to make, either to our service directly or to our documentation.
HEATHER FLANAGAN: Our first integrated workshop was in December. And our next one is at the end of March. So I expect we'll be talking quite a bit more about things like AB testing, which if you have any user experience experience in your background, you'll know that AB testing offering that is it this, does this make sense, how would you users click on that versus a different experience and where are users clicking on that, and getting that kind of metrics to let us know what's working and what isn't.
HEATHER FLANAGAN: Well, I'm sure you all now very fascinated and you want to know, how can I be involved in this? How can I get the latest and greatest news on what's happening with SeamlessAccess? Well, OK, so if you're in the library, and this is all kind of new to you, then you need to actually be making a couple of plans. You do need to talk to your campus IT a bit, see is SAML supported?
HEATHER FLANAGAN: Do you have privacy policies and attribute release policies that you need to work in? There are different vended solutions that could help you out with this. So exploring those a little bit, and just getting involved in conversations. There is a group that I would highly recommend if you're somewhat new to this space called the Federated Identity Management for Libraries, FIM4L, that is by librarians, for librarians talking entirely about federated identity and what they see as best practice in this space.
HEATHER FLANAGAN: OK, but let's say you are an identity provider, how do you get involved, and what do you need to do? Supporting entity categories would be a really big deal in terms of helping, not just SeamlessAccess but some of the other work that's out there. If you have any researchers or people doing research on your campus, you will find there's an entity category that focuses on that.
HEATHER FLANAGAN: If you have students or faculty that ever need to get to scholarly content, oh, there's the three entity categories we just talked about, you might want to consider supporting if they're approved. You also should go ahead and reach out to your campus librarians, because they have a lot of needs in this space. And maybe you don't have the same language to talk about that.
HEATHER FLANAGAN: But now's the time to really focus on building that bridge. They are going to be one of the biggest users of federated single sign-on services outside of your campus. And so their use cases are one that you have to become intimately familiar with. And service providers, for those publishers and other folks-- because this isn't just about publishers, you know. Any one that's offering federated identity services can be using the SeamlessAccess work.
HEATHER FLANAGAN: I strongly recommend you go to our website and start looking at the documentation that we have available. It's of course, available to anybody. But for service providers in particular, this is going to answer a lot of your questions about the gory, gory details of size of button, placement of button, language in the button, language around the button. It's like a prepositional phase, what can you do with the button-- by it, for it, around it, through it, under it, over it, all of it, that's in our documentation site.
HEATHER FLANAGAN: And if you just think that's all well and good, but that's perhaps a little bit more than you're up for, you can also just sign up for our monthly email. There's a link on the website to get there from here. Or if you're really interested in a particular working group that I've discussed, drop a note to contact@seamlessaccess.org and we'll see what we can do. And with that, thank you all very much for your time today.
HEATHER FLANAGAN: And I'm looking forward to the Q&A section that comes next.
JASON GRIFFEY: Thank you very much, Heather. That was great. Thank you, everyone. If you do have any questions, get those ready. We will move into a Q&A session. [MUSIC PLAYING]
Form Title Download
Video
Transcript
Form Title Bookmark
Entire Media
Segment(s)
Custom Clip
Start At:
End At:
Form Title Share
Entire Media
Segment(s)
Custom Clip
Start At:
End At:
Form Title Accessibility and Keyboard Shortcuts
The cadmore media player is a professional video and audio player experience designed to deliver media as well as relevant transcript, segmentation, and metadata. On the screen is a traditional html video player with buttons such as play, pause, forward, captioning, language and play speed selection and more. Adjacent to the video player are generally tabs, one of which shows a scrolling transcript of the video and the other shows any segmentation of the media, sometimes referred to as chapters. At the top of the video is a menu bar containing an Explore button and Tools button. The Explore button allows you to dig deeper into the video by opening up an explore dialog which contains tabs for a visual navigation of the video using thumbnails, an about tab which contains rich metadata about the media, a segments tab which contains further information about the video, and a related tab which contains links to other media related to this media. The tools button opens a menu with options for sharing the media on social media, creating bookmarking links, creating embed codes for your website, generating citations, and more.
Keyboard Shortcuts
Keyboard shortcuts only work while you are in forms mode. By entering forms mode, you will be able to quickly access portions of the media player with single key commands.
Spacebar: Play/Pause Toggle
I: Info Menu,
O: Tools Menu
T: Transcript Tab,
S: Segments Tab
F: Forward 15,
R: Rewind 15
L: Languages,
P: Playspeed
M: Mute Toggle,
V: Volume Bar
N: Video Only Toggle,
B: Full Screen Toggle
C: Captions Toggle
Escape: Closes dialogs and menus / Exits Player
Z: Next Transcript Chapter
X: Previous Transcript Chapter
Q: Next Transcript Paragraph
W: Previous Transcript Paragraph
Entire Media
Segment(s)
Custom Clip
Start At:
End At:
Embed Size
-
You Size - Responsive
-
We Size - Responsive
-
Picture Overlay Popup
-
400 x 225
-
512 x 288
-
400 x 700
-
768 x 1024
-
1024 x 512
-
1280 x 608
Form Title Cite
No citation provided.
Info
Segments
Related
Thumbnails
Exit Clip Mode
You have requested to see a portion of the video outside of the clip.
Click OK to switch to the full video or click if you would like to stay inside the clip. You can always go back to the clip with Tools and Clip Mode