Appendix G
(informative)
Security Considerations
(This appendix is not part of ANSI /NISO Z39.93-2007, The Standardized Usage Statistics Harvesting
Initiative (SUSHI) Protocol. It is included for information only.)
The SUSHI standard, which encompasses sushi.xsd and sushi.wsdl, does not include an
integrated security mechanism, however, security was a consideration in developing this standard. The
Working Group recognizes that, for many institutions, usage data and other information about their
collections are considered confidential and are covered by institutional security policies. Strong security is
possible without building a security mechanism into the standard protocol. This appendix discusses three
levels of security that can be implemented by SUSHI clients and servers. These are:
1) Securing the data communication channel
2) Authenticating the requesting organization (the SUSHI client software)
3) Validating the rights of a requesting organization to access usage data for a specific customer
G.1 Securing the Communications Channel
SUSHI is built on top of SOAP (Simple Object Access Protocol), which in turn uses either HTTP or
HTTPS for transmission between client and server applications. By using HTTPS, the communication
between client and server is encrypted using SSL (Secure Sockets Layer), thereby preventing any third
party from intercepting the transmission and discovering its content.
It is recommended that all SUSHI developers implement their Web services for HTTP and HTTPS.
G.2 Authenticating the Requesting Organization
Using HTTPS, the communication channel is secure, however, there is still a possibility that an
unauthorized software application could access a SUSHI server and request usage data. To prevent this,
the content provider can implement a security layer within their SUSHI server. Following are three
options:



Requestor ID validation
IP authentication
Username/password
The simplest form of authentication would be to validate the Requestor ID. Unless the Requestor is
known to the server, the request would not be processed. The Requestor ID can be a simple number
or code identifying the client, or, if stronger security is desired, the value for the Requestor ID could
include encrypted information, such as the domain of the client such that when the client submits the
SUSHI ReportRequest, the server can decrypt the Requestor ID to verify that the client is legitimate.
Adding IP authentication is another option to create much stronger level of security. The requesting
organizations would need to register the IP address of the computer running their SUSHI client software
with the service provider. The service provider would only process requests for recognized IP addresses.
When implementing IP authentication for SUSHI clients be aware that many of institutions will use a
hosted usage harvesting service, which means the same client with the same IP address may be making
requests on behalf of many institutions.
Note: to ensure interoperability of clients and servers do not use WS-Security extensions or similar
mechanisms to introduce username/password authentication to the SOAP or HTTP level.
G.3 Validating Rights of a Requesting Organization to Access Specific
Customer Data
Most content providers will store usage data for a large number of institutions and will also have a large
number of requesting organizations looking to harvest the usage data. The content provider can introduce
another security layer to restrict authorized requesting organizations to certain customer data.
The SUSHI ReportRequest contains the Requestor ID (identifying the requesting organization) and
the CustomerReference ID (identifying the organization whose usage is to be harvested). Service
providers can fairly easily set up a system that requires their customers to “authorize” requesting
organizations to harvest their data. If the service provider registers the requesting organizations, then it
can present their customers with a simple user interface that gives them the option to “activate” SUSHI
harvesting, then identify the requesting organization(s) allowed to do the harvesting. The result is a
mapping between CustomerReference IDs and Requestor IDs, allowing the SUSHI server to
verify that the data harvesting is permitted before processing is continued.
For service providers who are using IP authentication for the requesting organization, a simpler model
could be implemented when the requestor and the customer are the same. The SUSHI server could verify
that the IP address of the requestor is included in the IP range registered for the customer and, if so,
processing of the request would continue.
G.4 Summary of Security Considerations
Even though security is not part of the standard, SUSHI can be a very secure protocol. Using HTTPS, the
communication channel is secure. Service providers can authenticate the requesting organizations using
IP addresses and Requester IDs. Service providers can allow customers to have their data further
protected by first requiring them to opt in to SUSHI harvesting, then by identifying which requesting
organizations (i.e., SUSHI client implementations registered with the service provider) are allowed to
harvest their data.