OPAC
Introduction
OPAC (Online Public Access Catalog) is a digital system used by libraries to allow users to search for and access books, journals, and other resources. The login process for OPAC varies depending on the library system. Essentially, it is a specific IDP system.
Statista's implementation for this type of authentication only applies to the two following libraries:
- bib-karlsruhe - Stadtbibliothek Karlsruhe
- bib-goeppingen - Stadtbibliothek Göppingen
Notes and TLDR
- The OPAC method is only applied to two libraries
- We don't use the information returned by the library of the users actually authenticating, but always log the same user defined in our parameters (group account owner)
- We don't store any relevant data or track any of the information returned by the library except for checking the
statusparameter
Technological Overview
We use a generic connection on Auth0 to force create a session after the authentication is handled on the monolith. (Reference: LoginController.php)
This login functionality is a generic implementation that we use for several of our login methods, as a practical way to utilize the new authentication ways without necessarily reimplementing the whole flow with the corresponding customers. As part of the flow, the monolith contacts the library API (endpoints defined here). The form is created via the PHP code to collect the username and password of the user, which is then sent and validated via the library API.
Within the XML response of the api call, we get the confirmation of the user to be authenticated. Unfortunately, we always authenticate the user associated to the group account defined in our parameters file (here). This means that we send the correct individual users to the library IDP, but what we actually authenticate against is the user holding the account. If the service returns a 'status' parameter either 2 or 3, then we know that the user that is authenticating via their system is valid. It would be much more beneficial to us if we used the actual user that is authenticating against the library IDP. Since the system already processes the login information, we could adapt to track the number of users and store this data for a more personalized experience.
We then take the ID of the defined user to be logged in and sign it (Reference: signerService->sign). In turn this information is passed to Auth0, which is then forwarded to our platform-sso services that decodes and verifies this ID. It fetches the correct user from the legacy User DB and returns a successful (or not) authentication to Auth0, which then responds back to the remix-sso application.
Once this process is completed, the callback to the monolith happens after setting the __sso cookie with the correct information. On the next page load, the cookie is picked up and a user is injected into the PHP session.