KMLM List

[thomas barker <tbarker@xxxxxxxxxxxxxxx>]

If you have agreed to use HTTP why do we need wsse anyway?  I have to
imagine that HTTP-BASIC + SSL + Sushi Parameters is more than enough.  It's
enough for most sites that require credit cards.  Adding IP authentication
and wsse along with other discrepancies in sushi responses makes ingestion
very frustrating.

On Fri, Jul 16, 2010 at 10:32 AM, Luiz Augusto Garcia da Silva <
luizaugustogarcia@xxxxxxxxxxxx> wrote:

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