This section highlights some aspects of configuring PDS for OPAC via Primo and supplements both the PDS setup information provided in the Patron Directory Services Guide and the Voyager scenarios described in PDS Authentication for OvP to LDAP/Voyager.
The User ID - ALEPH & Voyager
Primo must include the user's ILS ID (which is the Z303_ID for Aleph and the patron ID for Voyager) when it communicates with the ILS for OPAC via Primo functionality. In many cases, customers prefer to send a campus-wide ID instead of the user's ILS ID. To accommodate these customers, Primo can accept the following types of IDs from the PDS server:
- Primo ID – In general, this is the ID that users sign in with. This is the ID that Primo uses for user-generated data such as on the e-Shelf.
- ILS API ID – The ID that Primo uses when it communicates with the ILS API for OPAC via Primo functionality. If this parameter is not included in the PDS response, Primo will use the Primo ID to communicate with the ILS.
Including the ID in the PDS Response
The PDS server activates two different requests against the authentication system. Both of the following requests can be made to the same system or to different systems:
- bor-auth – This process takes the username and password entered by the user and validates it.
- bor-info – After authentication completes, this process allows you to retrieve different user parameters.
The PDS response is an XML file that contains the following sections:
- bor_id – for the bor-auth response.
- bor-info – for the bor-info response.
The User ID can be included in both the bor-auth and the bor-info response:
- Primo ID – The ID that the user signed in as will be returned to Primo as the <id> field in the <bor_id> response to a bor_auth request. If this ID can serve as the Primo ID - no additional ID needs to be included. If the Primo ID is different from the ID, the <bor_info> response should include the ID that the user signed in with.</bor_info></bor_id></id>
- ILS API ID – if the Primo ID is not the internal ILS ID, then the internal ILS ID should be included in the <ils-api-id> field in the <bor_info> response to a bor_info request.</bor_info></ils-api-id>
<?xml version="1.0" encoding="UTF-8" ?>
<id>OHAD</id> <!-Primo ID returned from bor_auth -->
<id>1234556</id> <!-- Primo ID returned from bor_info. If included, it will override the <id> above -->
<ils-api-id>OHADRR</ils-api-id> <!-- ILS API ID-->
PDS has configuration that lets you map fields received from the authentication system to the PDS calling system - in this case Primo. You can add such mapping for the ILS API ID.
z303-id = ils_api_id
z305-bor-status,01 = group,STAFF
Getting the ILS API ID from the Bor_info Request
As noted above, it is possible to configure PDS to activate the bor_auth and bor_info requests against different authentication systems. For example, you can define the authentication process (bor_auth) to work with the LDAP server and the information retrieval process (bor_info) to work with the ILS (such as Aleph or Voyager). This means that if you use a campus-wide authentication system like LDAP or Shibboleth and it cannot return the internal user ID, you must configure the PDS server to send the bor_auth request to the authentication system and then send the bor_info request to the ILS. Both Aleph and Voyager have alternative user IDs that can be used to for the campus-wide ID. (In ALEPH - the Z308_ID; in Voyager the 'barcode', 'institution Id' & 'SSN'.
Additional Information Required for Voyager
In addition to sending the internal user ID, Voyager requires Primo to send the user's home database and recommends Primo to send the patron's group. Primo should receive both of these elements from the PDS server when the user signs in.
The home database should be sent in the <ubid> element and the patron group should be sent in the <group_id> element returned in the bor_info response.</group_id></ubid>
<?xml version="1.0" encoding="UTF-8"?>
<group>Undergraduate - full time</group>
The User ID - Alma
Alma's ILS API can accept any one of the user IDs that have been loaded into Alma. Unlike Aleph and Voyager, it does not need to be the main or internal ID. This means that the user's Primo ID must be loaded into Alma in order for My Account to function.