KMLM List

["BAKER, Chris" <chris.baker@xxxxxxxxxxxxxxxxxx>]

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 [sushidevelopers@xxxxxxxxxxxxx] On Behalf 
Of Luiz Augusto Garcia da Silva [luizaugustogarcia@xxxxxxxxxxxx]
Sent: 16 July 2010 14:06
To: Boerema, Cate
Cc: Andrew Wiles [aew]; Abdul Habra; Crego,Erin; 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.