KMLM List

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

    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] *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
> *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 [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.
>
>
> 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.
>
>