We are excited to announce a new tool in Springshare’s cloud platform of apps – LibAuth. LibAuth is our implementation of patron authentication inside Springshare apps and systems. This is important new functionality which will make Springshare tools even more useful and more applicable to a wide variety of use-case scenarios within libraries. We have big plans for LibAuth and will be enhancing it further to offer innovative authentication-based solutions and services to our libraries.
But first things first. LibAuth is a free module inside our LibApps platform. In essence, if you use any of our v2 tools (LibGuides, LibAnswers, LibCal, LibInsight, etc.) you automatically get LibAuth. Your Springshare LibApps admin configures LibAuth to link to the authentication method used at your institution. We currently support Shibboleth, LDAP, SAML, CAS, SIP2, and a remote self-hosted script option. If your institution relies on a method not listed here, please contact us and we’ll investigate how to make it happen! Springshare is also a member of InCommon and the UK Federation which makes authentication setup even easier for institutions who are members of either of these federations.
So, if you are the super-admin of Springshare tools at your institution (we call these LibApps admins) head to LibApps Dashboard -> Admin -> Manage Authentication (see screenshot below) and configure your authentication method.
Click on the “Manage Authentication” link in the navbar to enter the details of your authentication method and select attributes to release to Springshare. It is very likely that you will need to work closely with your IT folks to set this up so we recommend that you have your IT folks on good terms 😉 while setting up LibAuth. The setup form also provides testing tools to ensure you set things up correctly.
Pro tip: LibAuth also lets you define and configure any number of “rules” – for example if certain functionality should only be available to faculty or to undergraduates etc – as long as your authentication supports it and you release the necessary attributes to Springshare, you can setup all sorts of rules to be used in Springshare (and later in non-Springshare) apps.
Once you successfully setup your authentication scheme in LibAuth, here’s what happens next.
- At your option, your librarians with access to a LibApps account (to work on LibGuides, LibAnswers, LibInsight etc) can login to these tools using LibAuth, i.e. using their campus/library username/pwd.
- Starting tomorrow, LibCal room booking functionality is ready to work with LibAuth. Once you set up and verify your authentication method via LibApps, head to LibCal > Room Bookings > Settings > Edit Group to require LibAuth authentication for that group of rooms. If you’ve previously setup room booking authentication inside LibCal, we’ll automatically transfer those settings to LibAuth so you’re all set (but check the LibAuth console to confirm and do a couple of room booking tests, just to make sure).
- Over the next few weeks we will turn on authentication support for Event Registrations and Librarian Appointments so you will be able to restrict these (optionally of course) to your authenticated users (or groups) only.
- Over the next month we will turn on LibAuth authentication in our E-reserves module (our library reserves/reading list solution). This way our ER module will not only be the most affordable Reserves/Reading solution, but also one of the most secure ones too ;).
- In the next 3-4 months we will add support for LibAuth inside all of our apps, wherever and whenever needed. We’d love your feedback and ideas on this – email our support or sales teams and let us know where you think we should add authentication support (inside which Springshare apps and for what use-case scenarios). This is a really exciting and really big development for us, and we truly feel that adding authentication points inside our apps will bring many more use-case scenarios which will make your Springshare tools even more useful and will make you love ’em even more!
- Over the next 6-12 months we will be adding new products and services based on LibAuth capabilities, and we will be releasing an API to use LibAuth anywhere. Yes, we’re going there! We believe there are many opportunities ahead for providing seamless authentication that “just works” inside other library products and services. Send us your ideas, we’d love to hear from you.
Last but not least – please bear with us over the next few weeks regarding support and fixing any issues you may encounter while setting up your authentication method in LibAuth. We did tons of testing but with so many different authentication setups out there the best way to test and fix any issues is to release it into the wild and invite everyone to start using it. So while this is not “beta” because the full functionality is there and it works, we appreciate your patience while we ensure that it works well for everyone.
Thank you to all our clients who helped us during LibAuth development, with your excellent feedback and suggestions. We’re starting 2016 with a bang, and we have so many new things in store for our clients this year (and beyond). Thank you all for being the best clients, ever!
-Slaven & The Springshare Team
Hi Slaven, fantastic to see this development. It has been something we have been waiting for and its great to see the progression in products and services.
Hi Brad, thanks – our awesome clients (like yourself) are giving us great feedback and ideas so this is all happening because of you guys… keep ’em coming. Please email us a bit more detail about your earlier idea about SAML/Chat integration and we’ll see what we can do. Thanks much!
This is great! But what about those of us that are on non-standard LDAP ports? I’d really like to be able to enter the port number that we use here (because neither choice I can select is the open port at my institution).
Also, is adding LibAuth to E-Reserve in the works?
Hi Rebecca, please send an email to our support team about your LDAP non-standard port situation (with more detail about the port you are using and anything else that will help us) and I’m confident we’ll figure it out. To answer your second question, yes the LibAuth for ER is definitely in the works. 🙂 Thanks!
Is the LibAuth integration with the E-reserves module done yet, or is there a more exact estimate now that we’re at the end of January 2016?
Hi Bryan, it has not been done yet, we have been working on a few patches to the core authentication code and the ER module integration will be done next. Can you please send me an email with the desired specs how you would like to see the ER integration working? Thanks in advance!
Hi,
We’re about to launch room bookings with LibCal and are loving LibAuth.
We’re very excited about the possibility of using SSO for admin login to LibApps. I’ve just turned this on to see what it looks like – it would be great if there was an option to choose the default login e.g. SSO or LibApps (as we would prefer SSO to be the default and LibApps to be the alternative link).
Keep up the great work!
Cheers,
Suzy
Hi Suzy, it’s great to hear that LibAuth is working well for you inside LibCal. Regarding your suggestion about the login screen – thanks this is very useful. We’ll discuss internally how we can make this happen in one of the upcoming releases. Keep the feedback coming, and thanks for being on board.
We are beyond excited about this feature!
I tested the LDAP authentication and it worked using Distinguished Name for postfix for binding. But it didn’t work with User Principle Name (username@domain.com). If I use postfix as “@domain.coom” and test with “username”, it didn’t work. But if I used postfix as “domain.com” and added “@” sign to username like “username@” then it authenticated.
Asking user to enter username is “@” symbol at the end is not a good idea. Why postfix “@domain.com” is not working?
Hi Sunit, thanks for your note – I have forwarded your comment to our support team and they will be responding to you directly, via email.
What does it look like for a user who wants to reserve a study room? At what point do they have to authenticate if using Shibboleth, for example? Is it before viewing the rooms availability or after choosing a room/time and requesting? A screenshot would be really helpful.
Hi Michele – great question! Users are directed to your standard authentication page *after* choosing a room and time. I’ll include a screenshot so you can see what a submission would look like – essentially all of your room booking information is still public, but instead of being taken directly to your registration form, users will see a button to “Submit Time slots”, which will take them to your institution’s auth login screen. Once they enter their credentials, the user will then be directed back to LibCal where the full registration form will be waiting. Should you choose to release attributes like name and email address to us, we’ll use that information to fill out required fields in the registration form.
Thanks, hope this makes sense!