Ex Libris Alma is a pure cloud-based Software-as-a-Service (SaaS). Its architecture is based on leading cloud technologies, offering a secure, scalable SaaS. As a SaaS solution, Alma is accessible over the Web, requiring only a Web browser for the user. The move to a cloud-based SaaS offers great benefits and cost savings, together with faster response time to user requests. This document describes Alma cloud fundamentals, the technology driving the Alma cloud, the IT side of the Alma cloud infrastructure, and the Alma cloud's interaction with on premises institutional/campus systems.
The Alma Cloud Deployment Model
Ex Libris operates its cloud infrastructure as a private cloud, which is solely available for use by its customer community. This deployment model differs from a public cloud, which is available to the general public, or a hybrid cloud, which is a combination of two or more clouds.
Private cloud implementation provides Ex Libris with the opportunity to benefit from cloud computing without compromising on the architectural control required to ensure integrity of its customers’ data, systems, and processes.
This document goes hand-in-hand with Getting Ready for Alma and Discovery Implementation.
Making the Cloud Vision a Reality
The Alma system is based on multi-tenant architecture, in which the resources – both the software and the underlying infrastructure – are shared, in order to support all customers (“tenants”).
Strict data isolation is applied to all layers of the Alma application: user-interface branding isolation, database isolation (via Oracle Virtual Private Database), storage isolation, and FTP-level isolation, etc.
Ex Libris’ resources are focused on maintaining a single, current version of the application, rather than attempting to support multiple software versions for clients. As a result, no client is left behind when the software is updated with new features and innovations. Moreover, this delivery model enables Ex Libris to provide its customers with a fault-tolerant computing environment that includes dynamic resource allocation.
Because Alma is designed in accordance with the SaaS model, and deployed as a cloud-based service, it is Ex Libris' full responsibility to handle the software updates and upgrades. Ex Libris is committed to ensuring that its customers always have access to the latest features and incurs all the costs of maintaining and upgrading the required software. This enables all customers to fully take advantage of the latest Alma features and innovation.
Monthly releases and software updates are performed automatically by Ex Libris seamlessly, without any customer intervention.
Seamless Integration/Open Platform
Alma embodies Ex Libris’ Open Platform philosophy. This enables openness and interoperability between Alma and the other institutional/campus systems.
The Open Platform means open interfaces. It contains Web services, Web adapters, Application Programming Interfaces (APIs), plug-in interfaces, and more.
The Open Platform allows customers to share customer-written code so that one customer can benefit from the developments of another customer, leveraging the investments made by others for the benefit of everyone.
The following illustration demonstrates the various options for utilizing the Alma Open Platform to integrate with on premises systems that are part of the institution and library landscape.
Alma Open Platform
Cloud security and confidentiality are top concerns with cloud computing and SaaS architecture. Committed to providing its customers with the most secure and reliable environment, Ex Libris has developed a multi-tiered security model that covers all aspects of cloud-based Ex Libris systems. The security model and controls are based on renowned international protocols and standards and industry best practices, such as ISO/IEC 27001:2013 and ISO/IEC 27018:2014, the standards for an information security management system (ISMS).
Performance and Service Availability
Ex Libris is aware of the fact that the performance of its cloud applications can have a significant impact on customer adoption and satisfaction. Ex Libris’ cloud data centers leverage their infrastructure-renowned technologies and applications in order to meet the performance service-level agreements (SLAs) to which the Ex Libris is committed.
Moreover, Ex Libris employs a dedicated cloud services team, which is responsible for monitoring the applications and platform performance and issuing periodic SLA reports.
As a library management solution, Alma must communicate with different on premises library systems. This section describes the different on premises systems with which Alma may need to communicate and the communication methods used.
As a true cloud solution, Alma requires only a browser. Alma supports all the leading browsers: Chrome, Firefox and Internet Explorer. There is an ongoing process of monitoring new browser versions and certifying their compatibility with Alma. Full browser certification details for Alma can be found here. Browser support information for Primo can be found here, and for Summon here.
Browser to Alma communication is conducted using SSL, over ports 443. The URLs (domains) to be used are provided to you by your Ex Libris project manager.
Due to HTTPS network latency in APAC countries (which is not prevalent in other countries), Ex Libris provides both primary and alternate domain names. The primary domain name points to a server using WAN optimization. It is referred to as <Alma domain> in the documentation. In cases where the primary server is not working, or for non-HTTPS connections to Alma, use the alternate domain name, referred to in the Alma documentation as <Alma alternate domain>.
Similarly, primary and alternate delivery domain names are provided for APAC countries. The alternate delivery domain name is referred to in the documentation as <Alma alternate delivery domain>.
To function properly and completely, Alma must communicate with different on premises installed systems, such as financial systems, student information systems (SIS), self-check (SIP) machines, and other third-party systems.
The sections below describe the different components that Alma may communicate with outside of its cloud network. There is a table listing the different network communications used, as well as a network diagram illustrating the communication, protocol, and direction (in/out). Not all listed communications are necessarily relevant for each institution.
Ex Libris does not provide an FTP/SFTP server. If you need to store files on an FTP/SFTP server for file-based integrations with Alma, you must provide your own FTP server. Alma supports secure FTP (SFTP – over SSH, but not FTPS over SSL) using port 22 or standard FTP using port 21.
Alma IP Range
Some on premises systems with which Alma integrates (for example, ERP, SIS, SFTP, SIP machines) may require these Ex Libris regional IP/s in order to communicate with Alma.
The following IPs/IP ranges must be allowed access to/from your institution. (Note that the IP ranges below are in CIDR notation.)
- In North America (refers to the Ex Libris Chicago data center (also see Canada below)):
- 184.108.40.206/26 [220.127.116.11-191]
- 18.104.22.168/28 [22.214.171.124-207]
- 126.96.36.199/27 [188.8.131.52-159]
- In Canada (refers to the Ex Libris Canadian data center):
- 184.108.40.206/29 [220.127.116.11-71]
- 18.104.22.168/29 [22.214.171.124-135]
- 126.96.36.199/30 [188.8.131.52-127]
- 184.108.40.206/30 [220.127.116.11-191]
- In Europe (refers to the Ex Libris Amsterdam data center):
- 18.104.22.168/27 [22.214.171.124-191]
- 126.96.36.199/28 [188.8.131.52-143]
- In APAC (refers to the Ex Libris Singapore data center):
- 184.108.40.206/31 [220.127.116.11-17]
- 18.104.22.168/27 [22.214.171.124-63]
Note that access to the above IP ranges may require firewall settings at the institution level and inclusion in the institution's SPF DNS record (in order to avoid Alma emails potentially being handled as spam).
Primo IP Range
The following IPs/IP ranges must be allowed access to/from your institution. (Note that the IP ranges below are in CIDR notation.)
- In North America:
- 126.96.36.199 (MTNA01 and TCNA)
- 188.8.131.52 (MTNA02)
- 184.108.40.206 (MTNA03)
- 220.127.116.11 (MTNA sandbox)
- In Europe:
- 18.104.22.168 (MTEU01)
- 22.214.171.124 (MTEU02)
- 126.96.36.199 (TCEU)
- 188.8.131.52 (MTEU sandbox)
- In APAC:
- 184.108.40.206 (MTAPAC)
- 220.127.116.11 (TCAPAC)
- 18.104.22.168 (MTAPAC sandbox)
Summon IP Range
There are no special IP requirements for communicating with Summon; Summon’s IP requirements are covered by Alma’s. See Alma IP Range above.
|Number of Alma Named Users||Required Minimum Network Bandwidth|
|Up to 50||0.025 MB per user|
|Above 50||0.015 MB per user|
|Above 200||0.01 MB per user|
- 10 Alma named users = 0.25 MB
- 500 Alma named users = 5 MB
Ex Libris Primo customers that are also Alma users work with Primo in the Ex Libris cloud and thus benefit from a complete cloud environment and smooth updates of both solutions. Alma and Primo communicate within the Ex Libris cloud network and the only external communication is between patrons and Primo functions over port 80 or 443.
If you have PCs in your institution that are open only to specific servers and ports (and specifically to Primo), make sure that these PCs/firewalls are also open to the Alma server and port.
If the customer is using on premises / local Primo deployment, Alma communicates with Primo in a bi-directional manner, as follows:
- Alma to Primo: an OAI-PMH XML of published metadata is sent from Alma to Primo via Secured FTP over ports 21/22
- Alma-Primo: bi directional HTTPS communication of patron services over port 443
For more information on Alma-Primo integration, refer to the Alma-Primo Integration Guide.
Alma-Primo Patron Services
Patron requests delivered to Alma via Primo (Get It, View It, and so forth) are verified and authenticated prior to any service being rendered. The flow is such that patrons are first required to authenticate external to Alma. After they successfully authenticate, Alma communicates with Primo in a bi-directional manner, over a secured HTTPS port (443), in order to validate the patron authentication prior to providing the requested services.
Primo Back Office
In order for staff users to access the Primo Back Office, outgoing HTTPS communication must be allowed/opened on port 1443.
Alma-MetaLib (when MetaLib is in use)
For local installations of MetaLib, where MetaLib communicates with Alma for full-text indication, the communication between Alma and MetaLib is via API over HTTP port 80.
For hosted MetaLib, Alma and MetaLib communicate within the Ex Libris cloud network.
Summon and Alma are both hosted services and thus benefit from a complete cloud environment and smooth updates of both solutions. Alma and Summon communicate within the Ex Libris cloud network, and the only external communication is between patrons and Summon over port 80 or 443.
Metadata published from Alma to Summon is sent with secure FTP using port 2022.
Alma-Summon Patron Services
Patron requests in Summon (Get It, View It, and so forth) are verified and authenticated prior to any service being rendered. User authentication is provided by Alma. For more information, see the Alma-Summon Integration Guide.
Summon Admin Console
The Summon Admin Console is accessed by staff users through Alma, using port 443.
Alma – Self-Check Machines/SIP-based Systems
Alma supports communication over the SIP2 protocol, which is used primarily for communication with local self-check machines. The communication is bi-directional.
Since the vast majority of the SIP-based systems were built and designed without the cloud in mind, the SIP2 protocol lacks several components in order to fully support a cloud-based SaaS – namely, a unique institution ID and secure communication channel (which is supported in SIP3). Once SIP3 becomes the de-facto standard with cloud capabilities, Ex Libris will support it as well.
To secure SIP2 communication, Alma uses an open source SSL encryption wrapper called Stunnel (http://www.stunnel.org). This is a lightweight component installed locally on standard operating systems, such as Linux or Windows (see supported operating systems: https://www.stunnel.org/ports.html). This component creates a secure TCP "tunnel" communication over port 6443 with Alma and also serves as a means to uniquely identify and securely route each institution’s requests.
The communication flow is as follows:
- The SIP2 local machines communicate with Stunnel software that is installed on the local Windows/Linux workstation.
- The Stunnel encryption component encrypts the TCP communication using a standard encryption method and a security certificate, and will send the SIP2 requests to the Alma cloud over the secure port 6443.
The following diagram describes this architecture:
Alma Secured SIP Communication
Alma – Financial/SIS Systems/Vendor EOD, EDI/SMS (File-Based)
Alma exchanges data with local financial systems, student information solutions, and embedded order data (EOD) using files. FTP or secure FTP is used to facilitate this communication over ports 21/22. SMS communication is also file-based via FTP or secure FTP.
For information on integrating Alma with these systems, refer to the Alma Integration with External Systems Guide.
OCLC Connexion (Web or client) interacts with Alma using the TCP-based protocol. Communication occurs via a single port (5500), rather than multiple ports, in order to simplify implementation, while maintaining secure and separate access per institution to the service. This port is open on Ex Libris' side. Ensure that it is open for your institution as well for the workstations which require OCLC Connexion communication with Alma.
To support communication via port 5500, configuration is required in both Alma and OCLC Connexion (Client/Web). For details, refer to Importing Records from OCLC Connexion.
Resource Sharing (ILL)
Communication can be configured between Alma and a resource sharing partner - either peer-to-peer or broker-based. For details, see Resource Sharing Partners.
Peer-to-peer communication takes place over port 9001. Broker-based communication takes place over port 443.
Alma supports several different standard methods of sharing Alma title data with third-parties. Some involve standard online protocols to allow authorized individuals to search their Alma catalog directly (Z39.50 – TCP, OAI-PMH – HTTPS, SRU-SRW – HTTPS, Google scholar and other third-parties from the Discovery services page and Alma delivery – HTTPS).
Others involve publishing data for use outside of Alma (using Alma’s robust publishing platform) in a file-based manner using FTP or Secure FTP.
Institutions that use digital functionality must have HTTPS access to the Ingest and Delivery URLs specified in the S3 Regions and Buckets section of the following page:https://developers.exlibrisgroup.com...al/almadigital
To ensure data privacy, end-user authentication must be performed via an institutional identity management system (such as Lightweight Directory Access Protocol/LDAP, SAML 2.0, or CAS 2.0). Your external authentication system must be up and running properly before you can begin Alma implementation.
Alma supports authentication of staff users via the institutional LDAP (Lightweight Directory Access Protocol), using a secure connection. The connection should be secured with a certificate issued by a recognized certificate authority (such as Comodo, Verisign, or Thawte). To allow LDAP integration, the Alma Data Center IP ranges (mentioned above, according to your location) must be defined. You must also open the port for communication initiated by Alma in the firewall (port 636), as listed in the table below.
In addition, Alma supports SAML (Security Assertion Markup Language) and CAS, which are XML-based, open standard data formats for exchanging authentication and authorization data between parties via HTTPS—in particular, between an identity provider and a service provider such as Alma. The most important problem that SAML and CAS address is the Web browser single sign-on (SSO) problem. Alma supports the SAML 2.0 Web Browser SSO profile and CAS 2.0 Web Browser SSO profile.
For more information on LDAP, SAML, and CAS, refer to https://developers.exlibrisgroup.com.../inst_idp/ldap, https://developers.exlibrisgroup.com.../inst_idp/saml, and https://developers.exlibrisgroup.com...n/inst_idp/CAS, respectively.
As a cloud solution, Alma cannot simply be connected directly to your local network/printers due to security concerns and technical limitations. Printing from Alma, therefore, is handled via email. Each library/institution defines the email addresses of its local printers in Alma, which route staff-oriented, Alma-originating e-mails (including request and transit slips) to the appropriate printer.
Newer printers have their own built-in email addresses to support cloud computing. If you are using a new printer, therefore, the email address for notifications should be the printer’s email address.
Older printers do not support direct emailing and will therefore require a print proxy. There are several applications available to manage printer routing. For example:
- MS Outlook printing rules – It is possible to create an email address and link this address to a printer via your MS Outlook printing rules.
- Automatic Email Manager (AEM) by Namtuk – For details, see http://www.namtuk.com/
The above are examples only. Any print proxy that meets your institution's needs can be used.
Alma sends emails to users, patrons, vendors, and other recipients: acquisition requests, borrower activity status, hold request notifications, overdue reminders, and so forth. In some cases, recipients are expected to send responses to these emails; these responses should be entered manually into Alma (for record keeping; for example, vendor invoices).
Primo and Summon also send emails: catalog records, search alerts, and so forth. No responses are expected for these emails.
The default SMTP-Envelope-From address for these emails is what is defined for the From: address in the letter. In Alma, an administrator can change this using the mail handling integration profile; see Configuring Outgoing Email.
Note that the SMTP-Envelope-From address is different from the email’s message header From: address, which is used for replies and which can be configured separately for most emails.
- The SMTP Envelope-From address is used only by the mail server.
- The email’s message header From: address is used primarily by the email client (such as Outlook or Thunderbird). It may also be looked at by anti-spam filters.
The customer may want to change these two addresses to be email addresses within the customer’s domain, such as <somename>@cust_domain.edu for one or both of the following reasons:
- The customer wants all emails sent on their behalf to be branded with their own domain.
- The customer wants to receive bounce emails (automatic notification of non-delivered emails) directly to a mailbox on their own mail server.
To change these addresses to be email addresses within the customer’s domain:
- The customer must change EnvelopeFrom to a valid mailbox in the customer’s domain, for example library-bounce@cust_domain.edu.
- The customer must change the message header From: addresses in relevant Alma letters to addresses in the same domain used for EnvelopeFrom, for example library-noreply@cust_domain.edu. These addresses do not have to be valid mailboxes.
The customer must add an SPF Include Entry for the Ex Libris’ mail-relay servers into the SPF record of the customer’s domain (see Mail Relay Gateways).
Changing these addresses to be email addresses within the customer’s domain is not currently supported if the customer has implemented DKIM and/or DMARC in their mail infrastructure.
Mail Relay Gateways
Alma and Primo use dedicated mail-relay servers in each region. Summon does not use such servers.
Ex Libris supports Transport Layer Security (TLS) on the mail-relay servers to deliver mail securely.
Secure SMTP over TLS allows for encrypted messages; TLS uses Public Key Infrastructure (PKI) to encrypt messages from mail server to mail server.
The preferred (default) setup of the Alma email servers involves the use of encrypted transactions. If a customer’s email servers support TLS, Ex Libris upgrades the SMTP session to use TLS. If TLS is not supported on the customer’s email servers, Ex Libris establishes the session without TLS.
Alma email servers support encrypted emails (TLS) signed with a GoDaddy certificate. If a customer’s email servers support TLS, it is recommended that GoDaddy be added as a root certificate authority to the MTA. (Note that when the certificate is not verified, the email is delivered as “untrusted” to the customer.)
Ex Libris strongly recommends that the customer whitelist the IP addresses of Ex Libris’ mail-relay servers (see below) as permitted SMTP servers in any anti-spam filters managed by the customer or any email service to which they are subscribed.
The Ex Libris mail-relay server IPs and hostnames for Alma and Primo are as follows:
|Region||SPF Include Entry||IP Addresses / Range|
Only the SPF entry or IP address(s) in the customer’s region need to be included.
Ex Libris recommends using the SPF include entry listed above, rather than the IPs, since mail-relay IPs may change.
For whitelisting mail-relay IPs in mail filters for any European instance of Alma or Primo, both IP addresses must be added.
Network Communication Diagram and Table
The following diagram describes the different possible network communications with Alma.
The table below summarizes the complete network communication between the Alma cloud and the customer's network:
|Staff workstation||Staff workstation||Alma||HTTPS||443|
|Staff workstation||Primo (Back Office)||HTTPS||1443 (multi-tenant)|
|Staff workstation||Summon Admin Console (via Alma)||HTTPS||443|
|Patron workstation||Patron workstation||Primo||HTTPS||443|
|Staff authentication||Alma ||CAS (SSO) |
|Primo Central||Alma||HTTPS||443||Primo central registration with Alma URL|
|Alma-Primo end-user authentication||Primo||CAS (SSO) |
|Alma-Summon end-user authentication||Summon (via Alma)||CAS (SSO) |
|Alma||Email Server||SMTP||25||Print via email messages|
|S/FTP file-based integrations (outgoing)||S/FTP Server|| ||S/FTP||21/22|
|S/FTP Server||Publishing platform - Summon||S/FTP||2022|
|S/FTP file-based integrations (incoming)|| ||S/FTP Server||S/FTP||21/22|
|Ex Libris APIs (for more information, see the Developer Network)|| |
|Remote storage (for file-based remote storage, see S/FTP file-based integrations - outgoing above)||Stunnel workstation (Dematic ASRS remote storage facility system)||Alma||SSL-secured||6443||Using Stunnel|
|Alma||Stunnel workstation (Dematic ASRS remote storage facility system)||SSL-secured||5001||Using Stunnel|
|Self-check||Stunnel workstation (SIP2 Self-Check Stations)||Alma||SSL-secured SIP2||6443||Using Stunnel|
|Resource sharing (ILL) system (Alma or non-Alma)||Peer to peer resource sharing (ILL) system||Alma||TCP||9001|
|Alma||Peer to peer resource sharing (ILL) system||TCP||9001|
|Broker resource sharing (ILL) system||Alma||HTTPS||443|
|Alma||Broker resource sharing (ILL) system||HTTPS||443|
|RFID||Alma||RFID driver installed on a user's PC||HTTP||Determined by user||For more information on port configuration, see the Developer Network.|
|OCLC Connexion||OCLC Connexion||Alma||TCP||5500||Accelerated servers are not supported.|
|Google Scholar and other third-party electronic service providers||Electronic service provider||Alma (via Discovery)||HTTP or HTTPS||80 or 443||Via Discovery services page directed to Alma’s delivery services|
|Z39.50 data providing||Z39.50 server||Alma||TCP||1921 or 210||210 is open on all production environments; sandbox environments support only 210|
|OAI-PMH data providing||OAI||Alma||HTTPS||443|
|SRU-SRW data providing||SRU-SRW||Alma||HTTPS||443|
|Aleph Central Catalog for Aleph contribution||Alma||Aleph||HTTP or HTTPs||Institution-specific port definition|
|Aleph Central Catalog for Aleph bibliographic record updates||Alma||Aleph||TCP||Institution-specific port definition|
|Aleph Central Catalog for Aleph retrieving bibliographic records (external search)||Alma||Aleph||TCP||Institution-specific port definition|
|Aleph Central Catalog for SBN contribution||Alma||SBN||HTTP||Institution-specific port definition|
|Aleph Central Catalog for SBN retrieving bibliographic/authority records (external search)||Alma||SBN||HTTP||Institution-specific port definition|
|Electronic access proxy (EZProxy, etc.)||Alma||Proxy||HTTPS||443|
|Deposit using SWORD||Alma||Alma SWORD server||HTTPS||443|
|Online payment||Alma||WPM education system||HTTPS||443|
|Primo||WPM education system||HTTPS||443|
|Learning Tools Interoperability (LTI)||Course management system||Alma||HTTPS||443|