Authentication methods and patron data load

Laatst bijgewerkt
Opslaan als pdf

Learn about the requirements and patron load process for your authentication method.

The process for adding new patron data can depend on your library's authentication method. Find your authentication method below to learn more about authentication requirements and patron load process.

Note: If your library uses Tipasa there are additional considerations noted in the table below.

Authentication method	Authentication requirements	Is a patron load required?	How will I add new patrons?
LDAP	External-facing IP/server name accessible from outside your network Needs to be secure LDAP (LDAPS or LDAP with StartTLS) Ability to open firewall to a list of OCLC IP addresses Your LDAP server must be running on port 636. Your Root CA certificate from your LDAP server (if your cert is self-signed or not issued by a major certificate authority). Implementation team will alert you if a certificate is required. Test account required	In most cases, yes. Both an initial load and ongoing loads are required. Tipasa only: Provision on demand (where accounts are created as users log in using information returned by your LDAP server) is available. With this option no load is required.	Without provision on demand - Patron load only OR Tipasa only: With provision on demand - accounts get created as users log in with their LDAP credentials. This method creates patron accounts which only contain name, email, and LDAP identifier (usually samAccountName). It is possible to include address and phone.
CAS	Access from test and production OCLC URLs CAS server URLs GET requests are not currently supported Test account required To use the Digby mobile app, your institution’s Identity Provider (IdP) must accept the ForceAuthn flag. Support of ‘ForceAuthn=true’ is required so that Digby can properly manage user authentication. ForceAuthn is supported for basic WorldShare authentication. If your library uses a CAS or a SAML-based IdP (e.g., Azure, Shibboleth, etc.), you may ask your local IT department for assistance to confirm or update your institution’s IdP configuration	Ja	Patron load only
SAML (includes Shibboleth, AD FS, Azure, Google SAML, Okta, etc.)	SAML 2.0 or above Exchange of Shibboleth-related metadata between OCLC and your institution Persistent ID which will be presented from your Assertion/Subject/NameID from your SAML response If you cannot send a persistent ID in the Subject/NameID, you can provide us with the name of an attribute that can be sent as a unique, persistent value. Test account required To use the Digby mobile app, your institution’s Identity Provider (IdP) must accept the ForceAuthn flag. Support of ‘ForceAuthn=true’ is required so that Digby can properly manage user authentication. ForceAuthn is supported for basic WorldShare authentication. If your library uses a CAS or a SAML-based IdP (e.g., Azure, Shibboleth, etc.), you may ask your local IT department for assistance to confirm or update your institution’s IdP configuration Tipasa only: If using provision on demand, Azure requires Azure AD Premium 1 or E3 plan. If using a Patron load, any version of Azure can be used.	In most cases, yes. Both an initial load and ongoing loads are required Tipasa only: Provision on demand (where accounts are created as users log in using attributes returned by your IdP) is available. With this option no load is required.	Without provision on demand - Patron load only OR Tipasa only: With provision on demand - as patrons log in to your SAML IdP (if sufficient attributes are being released - at least name fields and email addresses). This method creates patron accounts which ONLY contain name, email and NameID from your IdP.
Basic WorldShare authentication	You must require a specific unique value from each patron (could be a username, barcode, student ID, or email address) You must also have the email address of your patrons (so that they will be able to receive instructions for setting up their password and so that they can receive notifications from circulation and/or Interlibrary Loan)	Initial load is required. Ongoing loads are strongly encouraged to add and update users. Tipasa only: Initial load is recommended, but you can also allow patrons to self-register for accounts in Tipasa. Self-registered accounts will only include name, email, and an additional identifying piece of information you define (which will be used as the username).	Patron load OR Library staff can add users via the Staff Admin interface. OR Tipasa only: Users can self-register for their own accounts, which are instantly active.
Tipasa only: ILS-based authentication methods (only SIP or III Patron API using EZproxy in the middle to act as a translator). This setup does not support CAS or SAML methods. EZproxy can only facilitate LDAP authentication for Tipasa.	You must have EZproxy (either hosted by OCLC or by your institution) Your EZproxy server must be using a valid SSL certificate Your SIP server or III Patron API must permit access from the IP of your EZproxy server Your EZproxy server must be running on either port 443, 8443, or 8447 Test account required	No. You can do an initial load, but it is not required. In most cases, libraries that select this method do not do a patron load.	Patron load OR Provision on demand (using their existing ILS-based credentials). Provision on demand creates accounts with just name, email, and a username (which could be a barcode).