KMLM List

["Crego,Erin" <cregoe@xxxxxxxx>]

In my case, I just figured the user and password could go onto the URL
as additional parameters to the service.  I tested it using the MISO
client and it seemed to work.  The drawback might be that the URL
differs between users since they obviously would have different
usernames and passwords.  I didn't realize it would be a problem since
the doc stated recommendations rather than requirements.

 

We're more than happy to move to using the RequestorId field of the SOAP
message.  We are trying to leverage the existing authentication
mechanism used to get into our stats site.  In the next release, we will
have username and password along with some delimiter field as the
RequestorId.  

 

Thanks.

Erin Crego



From: Boerema, Cate [mailto:Cate.Boerema@xxxxxxxxxxxxxxxxxxxx] ;
Sent: Friday, July 23, 2010 1:33 PM
To: Johnson, Alan; Luiz Augusto Garcia da Silva; Oliver Pesch
Cc: BAKER, Chris; Andrew Wiles [aew]; Abdul Habra; Crego,Erin;
sushidevelopers@xxxxxxxxxxxxx
Subject: RE: [sushidevelopers] new sushi deployment for testing

 

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 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.