KMLM List

["Johnson, Alan" <Alan.Johnson@xxxxxxxxxxxxxxxxxxxx>]

I agree with Luiz in that there are enough fields already defined in the schema 
to provide an adequate level of security to protect usage reports in the vast 
majority of cases.  SUSHI sites which require anything not fitting into the 
existing approach create hurdles for solutions developers who must overcome 
them on a one-off basis, which decreases the value of having a standard.

Defining an "acceptable" level of security should be the responsibility of each 
provider.  I wouldn't recommend mandating a minimum security standard as part 
of attaining Counter compliance.

If a provider wants/needs to go beyond what is currently defined by SUSHI, a 
"recommended" higher-security solution would be nice to have.

Thanks,
Alan Johnson

From: sushidevelopers@xxxxxxxxxxxxx [mailto:sushidevelopers@xxxxxxxxxxxxx] On ;
Behalf Of Luiz Augusto Garcia da Silva
Sent: Friday, July 16, 2010 7:33 AM
To: Oliver Pesch
Cc: BAKER, Chris; Luiz Augusto Garcia da Silva; Boerema, Cate; Andrew Wiles 
[aew]; Abdul Habra; Crego,Erin; sushidevelopers@xxxxxxxxxxxxx
Subject: Re: [sushidevelopers] new sushi deployment for testing

    I particularly think it would not take more than three fields to designate 
who is asking for a SUSHI report. A username, a password and another 
information to complement the request in order to identify if the requestor is 
a consortia, with an own code, or a member for example. Note that in several 
cases Requestor ID simply is ignored by the publisher. We can see that in the 
SUSHI Server Registry, where there are many occurrences of  "Any string of 
numbers or letters will be accepted. Please do not use "?" or other 
nonalphanumeric characters. " as instruction to fill that field.

       Specifically about authentication/authorization, maybe NISO SUSHI had to 
have emphasized the use of "wsse", for example, for passing the related 
parameters. Perhaps this could be included in future versions of SUSHI 
specification.

Luiz Augusto

On 16/07/2010 11:09, Oliver Pesch wrote:
Authentication was a bit of a tricky discussion when we first developed the 
standard so we kept things as simple as possible for the initial release.  
Having said that, I believe we might still have an opportunity to set out some 
guidelines and expectations through COUNTER.  Since COUNTER is the 
"enforcement" body for its Code of Practice and the Code of Practice includes 
SUSHI as a compliance requirement, we may be able to have authentication 
expectations added to the Code of Practice such that for a content provider to 
be COUNTER compliant an approved authentication method must be used (the 
methods being laid out in the code of practice.)

Perhaps we could allow one form of extended authentication (e.g. wsse) so that 
content providers have an option if feel they need authentication beyond what 
could be implemented using the RequesterID and CustomerID.  This approach, if 
acceptable by COUNTER (I have an email in to them already), could be 
implemented without having to revise and revote the NISO standard (a time 
consuming process).  In essence, our "Community Profile" for this standard 
would be reflected in the COUNTER Code of Practice.

We would welcome any thoughts on an approach like this.

Oliver
________________________________
From: sushidevelopers@xxxxxxxxxxxxx<mailto:sushidevelopers@xxxxxxxxxxxxx> 
[mailto:sushidevelopers@xxxxxxxxxxxxx] On Behalf Of BAKER, Chris
Sent: Friday, July 16, 2010 8:59 AM
To: Luiz Augusto Garcia da Silva; Boerema, Cate
Cc: Andrew Wiles [aew]; Abdul Habra; Crego,Erin; 
sushidevelopers@xxxxxxxxxxxxx<mailto:sushidevelopers@xxxxxxxxxxxxx>
Subject: RE: [sushidevelopers] new sushi deployment for testing

Personally, I think that SUSHI missed an opportunity by not defining a 
mechanism for authentication.

Maybe future versions of the SUSHI standard should specify the authentication 
mechanism - that would make all SUSHI clients and server inter-operable, make 
it easier to build a robust SUSHI client, and therefore help make SUSHI more 
usable..
________________________________
From: sushidevelopers@xxxxxxxxxxxxx<mailto:sushidevelopers@xxxxxxxxxxxxx> 
[sushidevelopers@xxxxxxxxxxxxx<mailto:sushidevelopers@xxxxxxxxxxxxx>] On Behalf 
Of Luiz Augusto Garcia da Silva 
[luizaugustogarcia@xxxxxxxxxxxx<mailto:luizaugustogarcia@xxxxxxxxxxxx>]
Sent: 16 July 2010 14:06
To: Boerema, Cate
Cc: Andrew Wiles [aew]; Abdul Habra; Crego,Erin; 
sushidevelopers@xxxxxxxxxxxxx<mailto:sushidevelopers@xxxxxxxxxxxxx>
Subject: Re: [sushidevelopers] new sushi deployment for testing
    It's true!
It has been difficult to collect statistics from all our publisher/platforms, 
because each one has requires that the authentication is done in a different 
way. Some of them use "wsse" over HTTPS. Others expect authentication 
credentials in Requestor ID and/or Customer ID. Others expect authentication 
parameter passed in HTTP BASIC Authorization headers (in a lowest level). SUSHI 
clients that are available on the network can not fit all.

    What we, from Brazilian CAPES Consortia, did was use the code of University 
of Pennsylvania's SUSHI Toolkit, availabe at 
https://labs.library.upenn.edu/SushiToolkitDocs/site/ as the basis of our own ;
SUSHI client. We made some changes in order to support "wsse", and particularly 
HTTP BASIC Authorization.

    After these troubles and changes in order to solve them our SUSHI client is 
able to collect statistics from all our publishers.


 On 15/07/2010 20:36, Boerema, Cate wrote:
It is going to be really difficult to develop a SUSHI client that works with 
all providers if they aren't aligned around the standard.  Our SUSHI client is 
currently expecting authentication to be passed through any of the SUSHI 
standard request elements.  If any provider wants to test authenticating that 
way we'd be happy to help them test using our client.

From: Andrew Wiles [aew] [mailto:aew@xxxxxxxxxx]
Sent: Thursday, July 15, 2010 7:16 AM
To: Abdul Habra; Crego,Erin
Cc: Boerema, Cate; 
sushidevelopers@xxxxxxxxxxxxx<mailto:sushidevelopers@xxxxxxxxxxxxx>
Subject: RE: [sushidevelopers] new sushi deployment for testing

Another method we've seen used for authentication are the WSS extensions to 
SOAP requests. ProQuest and Swetswise use this method.

From: sushidevelopers@xxxxxxxxxxxxx<mailto:sushidevelopers@xxxxxxxxxxxxx> 
[mailto:sushidevelopers@xxxxxxxxxxxxx] On Behalf Of Abdul Habra
Sent: 15 July 2010 14:42
To: Crego,Erin
Cc: Boerema, Cate; 
sushidevelopers@xxxxxxxxxxxxx<mailto:sushidevelopers@xxxxxxxxxxxxx>
Subject: Re: [sushidevelopers] new sushi deployment for testing

I found this attached pdf on niso site. 
http://www.niso.org/apps/group_public/download.php/2650/SUSHIauthentication20aug09.pdf

If I understand it correctly, It states that the user name/password could be 
embedded in the RequestorID

Additionally, SOAP allows the envelope to be posted with an http GET (and POST 
of course)
So if the client uses GET, adding username/password as parameters to the URL, 
would it not break the soap request?



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.

CONFIDENTIALITY NOTICE This email and any files transmitted with it are 
confidential and solely for the use of the intended recipient. It may contain 
information which is covered by professional or other privilege. If you are 
neither the intended recipient of this email nor the person responsible for 
delivering it to the intended recipient, be advised that you have received this 
email in error and that any use of it is strictly prohibited. Please notify the 
sender immediately by reply email and then delete it from your system. EBSCO 
accepts no liability for any loss or damage suffered by any person arising from 
the use of this email. Please consider the environment before printing this 
email.