KMLM List

["BAKER, Chris" <Chris.Baker@xxxxxxx>]

Hi Tom,
When we implemented SUSHI at Oxford University Press we also looked for 
guidance in the SUSHI protocol about security, but didn't find any. In fairness 
to the inventors of SUSHI I can see whay they might not want to specify 
security systems as part of the standard - but like you we were worried about 
interoperability in the absence of any guidance.

So what we did was to fall in line with the security system that EBSCO had 
already adopted - it met our needs well, and we thought that it might evolve 
into a de facto standard for SUSHI server security protocols, which would be 
good for interoperability.

I'll quote you Oliver Pesch's description of this system (from his email to the 
list 11 March 2009)


"The basic approach taken by EBSCO is as follows.

Each client is assigned a RequesterID which is "registered" in our
administration module.  Within the administration module customers can
grant harvesting rights to one or more registered client.

When a SUSHI request comes in to the server the SUSHI client is
authenticated (usually by IP); the RequesterID checked to make sure it
is registered; the CustomerID in the request is also checked to make
sure it is valid; and, a further check is made to ensure the customer
has authorized that particular client to harvest its usage.

The above works well for centrally hosted solutions like ScholarlyStats,
Serials Solutions, etc. where the same client harvests for many
customers. For locally hosted solutions the authorization can be much
simpler.  The IP of the SUSHI client can be checked against the IP range
registered for the CustomerID the usage is being requested for.  If the
IP is in the range, usage is provided, if not, the request can be
rejected."

What we do at OUP is the same - we invite customers to register IP addresses 
for SUSHI (their own, a third party contactor they are using such as Scholarly 
Stats; or a web-based SUSHI client such as the UNiversity of Pennsylvania one). 
They do this via a web form which is only available within our COUNTER 
webserver (so that you must be an authenticated COUNTER customer to set this up)
When SUSHI requests arrive, we do the double-check that Oliver describes -  "do 
we accept requests from this IP address?", second "is the RequesterID one that 
we expect from this IP address?". If both checks pass, the SUSHI request is 
served.
We log requests to the SUSHI server so that we can look for anything unusual in 
the requests that do/don't make it.

This seems a reasonable level of security to impose - we want to avoid 
customers getting hold of someone else's data: a mis-typed requesterID could 
potentially lead to a lot of confusion otherwise, and publishers and 
institutions may well regard usage data as confidential. On the other hand, we 
decided not to lock the server right down: there's usually a balance between 
convenience and security!

Hope that helps!

Chris Baker
(Project Manager for OUP SUSHI project in 2009)
________________________________
From: sushidevelopers@xxxxxxxxxxxxx [sushidevelopers@xxxxxxxxxxxxx] On Behalf 
Of Tom Demeranville [Thomas.Demeranville@xxxxxxxxxxxxxx]
Sent: 20 January 2011 09:41
To: sushidevelopers@xxxxxxxxxxxxx
Subject: [sushidevelopers] Gray areas: AuthN&AuthZ - Requestor ID/Customer ID

Hello Sushi list,

I’m designing a SUSHI server at the moment and I’ve hit a couple of gray areas. 
  I’m hoping the list can help me out.


1)       Although the specification talks about security, it’s rather vague and 
doesn’t talk about interoperability, and I’ve also found contradictory 
recommendations in other documents.  For me, there are two main requirements, 
that it’s secure and that it interoperates.  What should I be implementing to 
be compatible with existing clients?

2)      I’m confused about the role of Requestor ID vs Customer ID.  Some 
documentation states the Requestor ID is the client/service requesting the data 
and Customer ID identifies the customer.  Is this the case?   A quick glance at 
the list of current SUSHI servers shows that services are using these fields in 
many different ways.

Tom.

Oxford University Press (UK) Disclaimer

This message is confidential. You should not copy it or disclose its contents 
to anyone. You may use and apply the information for the intended purpose only. 
OUP does not accept legal responsibility for the contents of this message. Any 
views or opinions presented are those of the author only and not of OUP. If 
this email has come to you in error, please delete it, along with any 
attachments. Please note that OUP may intercept incoming and outgoing email 
communications.