KMLM List

["Andrew Wiles [aew]" <aew@xxxxxxxxxx>]

I've been through the list of vendors I have working configurations for and 
have the following authentication methods:
Username in Requestor ID, password in Customer ID.
Username + Password in a WSS Security SOAP extension.
Username + Password in a slightly different WSS Security SOAP extension 
implementation.
Username + Password in Customer ID with a delimiter between them.
Username + Password in HTTP Auth headers, Requestor ID and Customer ID still 
needing to be site specific.
Username + Password being passed as HTTP GET parameters.

Some of the above are also combined with IP authentication.
In my SUSHI client I've got 4 different SOAP templates that are used depending 
on which provider I'm harvesting from as well as a flag for the HTTP Auth 
header.
By the time everyone rushes to get their SUSHI service up and running to get 
their COUNTER compliance stamp, I wouldn't be surprised if I had another 4 on 
top of that.

Thanks,
Andrew


--
Andrew Wiles
Tîm Cynorthwywyr Pwnc ac E-Lyfrgell / Subject Support & E-Library Team
Gwasanaethau Gwybodaeth / Information Services
Llyfrgell Hugh Owen Library
Prifysgol Aberystwyth University
SY23 3DZ
Ffôn/Tel 01970 623111 x4276
E-bost/Email andrew.wiles@xxxxxxxxxx<mailto:aew@xxxxxxxxxx>
Gwe/Web http://neidio.aber.ac.uk/?lv / http://jump.aber.ac.uk/?nv




From: sushidevelopers@xxxxxxxxxxxxx [mailto:sushidevelopers@xxxxxxxxxxxxx] On ;
Behalf Of Boerema, Cate
Sent: 16 July 2010 00:36
To: Andrew Wiles [aew]; Abdul Habra; Crego,Erin
Cc: sushidevelopers@xxxxxxxxxxxxx
Subject: RE: [sushidevelopers] new sushi deployment for testing

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?