KMLM List

["Oliver Pesch" <OPesch@xxxxxxxxx>]

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
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/SUSHIauthenticat
ion20aug09.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.