KMLM List

[Luiz Augusto Garcia da Silva <luizaugustogarcia@xxxxxxxxxxxx>]

    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
> *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] *On Behalf Of *Abdul Habra
> *Sent:* 15 July 2010 14:42
> *To:* Crego,Erin
> *Cc:* Boerema, Cate; 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?