I agree - what Janifer is talking about is a user authentication token -
not a session id. The original objection to Janifer was that a session
id is much more easily forged than a username as password (as Rob has
pointed out a session id may be little more that an incremented number).
For an authentication token to represent a username/password pair
without opening up spoofing attacks you need something far stronger than
a session id - or a permanent open socket ala classic Z39.50.
Such an authentication token would probably be sent in SRW in the SOAP
Header - to generalise we want to say that the SOAP Envelope may contain
an authentication token which may be a username/password pair.
> -----Original Message-----
> From: Theo van Veen [mailto:[log in to unmask]]
> Sent: Friday, June 14, 2002 2:17 PM
> To: [log in to unmask]
> Subject: Betr.: Re: result set model for srw
> When we want the ability for identification/authentication this "user
> identification value" (lets say ticket) should be a specific SRU/SRW
> parameter and we should call and treat it that way and not confuse it
> a session-id.
> Obtaining this ticket should in fact be a separate webservice and
> used by the organisation for different purposes and this function does
> have to be the responsibility of of the same department that provide
> I would be happy with such a field that is optionally sent along with
> each request to those servers requiering it. When a user is not
> the server returns a diagnostic and the URL of the authentication
> The authentication server request user name and password and returns
> ticket (presumably with an encryption for which the SR-service has the
> key). Transfer of this ticket from the webpage requesting it to the SR
> webpage is still open.
> >>> [log in to unmask] 14-06-02 14:36 >>>
> I support Rob in his argument for a session id. In July last year, I
> submitted the following to the list:
> > We would also like the Search response to include a "server user id
> substitute". This can be returned in the ZNG:user
> > field for subsequent requests and avoid the user id and password
> be sent in multiple requests. It can also
> > serve to guarantee the "actual user" (there may be more than 1 user
> to use the same user ID/password) a time slot
> > on the server, because the system has a finite number of concurrent
> Pica also uses this for being able to
> > return search history, i.e. a notion of session, but this is out of
> At the time "session id" was a politically incorrect phrase. In our
> implementation of ZING/SRU we are adding session id into the actual
> within the URL. We need it in the request so that we can control
> it doesn't work if it is in a different layer.
> It's not complicated; it's just an optional element. Our server will
> it with the result set id and it expects it to be returned.
> In July last year we also had a lot of discussion about deleting
> sets. Ray's prose accurately reflects this discussion and I think it
> correct and reflects reality. Our server (along with lots of others)
> decides when it's time to do its own housekeeping with result sets
> told otherwise, i.e. with the TTL. It will even override the TTL if
> Janifer Gatenby
> Consultant OCLC PICA ITC
> Schipholweg 99, 2300 AW Leiden, The Netherlands
> + 31 71 524 65 00
> + 31 71 522 31 19 (fax)
> [log in to unmask]
> -----Original Message-----
> From: Robert Sanderson [mailto:[log in to unmask]]
> Sent: Friday, 14 June 2002 12:37
> To: [log in to unmask]
> Subject: Re: result set model for srw
> Theo, paraphrased:
> > You just need the request parameters.
> No. This would work if resultsets only last for one response/request.
> However if I were to do a search, do a second search and then try to
> combine the resultsets from those two searches, the first would have
> already disappeared. You need a session id (or to return ALL of the
> parameters from ALL of the requests to date made by the client, which
> would quickly overflow most URL implementations in SRU.
> > > I could send continuous (SOAP is HTTP/1.1 so includes
> > > pipelining and gzipping, making this even more effective)
> > > requests to trash random resultset names.
> > Yes, but I could send continuous requests to trash random session
> > client ids too! Or even better sniff the wire for the session
> > ids and use those. So introducing a session id in addition to a
> > set name just adds complexity without actually solving the problem.
> Packet sniffing is much harder these days than it was, due to
> networks. It's still possible using ARP poisoning, but I digress.
> Yes, introducing a session id doesn't make it impossible to do, but it
> does make it exponentially more difficult. Difficult enough that an
> attack is unlikely to succeed, whereas without it it is very possible.
> Compare basic authentication of username and password. Guessing a
> username and password combination is much harder than guessing one of
> two. And for large robust servers (the reason we're using SOAP
> there will be a lot of users. Unless the server is designed with this
> sort of security in mind, the resultsets will probably just identified
> with an incrementing scheme rather than a random set of characters, so
> once a pattern has been found, the server is completely compromised.
> User/password authentication has served for many years, and will
> continue to do so for all but financially important traffic.
> > A solution would be for the server to keep tracking of the source IP
> > Addresses - using that to identify clients and using result set
> > at present for maintaining state. Even that is foolproof since you
> > spoof ip addresses.
> > If you really want more resilience against this attack than you
> > use SSL (HTTPS) with client certificates to identify the client.
> Yes. But then you drastically limit the number of potential clients
> those that support encrypted SOAP. It also makes it more difficult to
> just throw together a server, I wouldn't bother... Z39.50 is less
> and more functional.
> > In any case client identification (if required) is an Out of Band
> > which can be resolved at other layers in the syste and needn't be
> > included in the SRW spec.
> Unless you have a web proxy, or specialised SRW proxy that multiple
> clients send their requests through, not an uncommon event I would
> For example, if I were to set up a cgi script that interogated SRW
> servers, I would want to map my local users to session ids. Except
> all coming from the same IP address so the server will map them all to
> same client. At this point you once again need some sort of session
> ,'/:. Rob Sanderson ([log in to unmask])
> ,'-/::::. http://www.o-r-g.org/~azaroth/
> ,'--/::(@)::. Special Collections and Archives, extension 3142
> ,'---/::::::::::. Twin Cathedrals: telnet: liverpool.o-r-g.org
> ____/:::::::::::::. WWW:
> I L L U M I N A T I