KMLM List

[Abdul Habra <ahabra@xxxxxxxxxxxxxxxxxxxx>]

For the service I am developing, we need the client to pass us a user id and a 
password.
We use the Requestor.ID for user id, and use CustomerReference.Name for the 
password.
The schema states that CustomerReference.Name is optional, and we do not have a 
special meaning for CustomerReference,
so I am proposing to use CustomerReference.Name for the password. What do you 
guys/gals think?


On Jul 23, 2010, at 1:33 PM, Boerema, Cate wrote:

> I discussed this a bit internally at SerialsSolutions.  Our thinking is that 
> SUSHI Server Authentication should include any or all of the following, with 
> each provider determining the level of security they feel is appropriate. We 
> think that the combination of these three methods would ensure a secure 
> transaction and that no additional security should be required.
> 1.       Basic: Library and content provider agree upon a unique, secret 
> password which will be passed through an existing SUSHI request element 
> (RequestorID?).
> 2.       Optional: Content provider requires that requests originate from 
> approved IP addresses.
> 3.       Optional: Content provider implements SUSHI server using SSL, thus 
> encrypting the data transmission so that neither the password nor the usage 
> data can be intercepted.
>  
> This is all pretty straightforward stuff that would be easy to implement and 
> work with from both the client and server side.  Do others agree?  Any reason 
> why additional security would be needed?
>  
> Thanks,
>  
> Cate Boerema
>  
>  
> From: Johnson, Alan 
> Sent: Friday, July 16, 2010 8:17 AM
> To: Luiz Augusto Garcia da Silva; Oliver Pesch
> Cc: BAKER, Chris; Boerema, Cate; Andrew Wiles [aew]; Abdul Habra; Crego,Erin; 
> sushidevelopers@xxxxxxxxxxxxx
> Subject: RE: [sushidevelopers] new sushi deployment for testing
>  
> 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] 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 
> athttps://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?
>  
>  
> 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. 
>  
>