"As a self service device developer I would like to be able to verify that the ID and PIN that a patron has provided are correct."

[MarkOliver]

"As a self service device developer I would like to be able to verify that the ID and PIN that a patron has provided are correct."

This has some overlap with the earlier discussion about "Authentication & Access Logs"...

I need to be able to verify if the credentials provided by a user are correct. Considering REST and that earlier discussion it appears that this shouldn't be a GET as the PIN needs to be safely encrypted in the body of the message. I don't want to do an update or a create of the user, so it's not a POST or a PUT of the Patron entity.

I'd be in favour of this being a new small service/interface of its own, adding functionality to the interface and not just CRUD. I've been circling DDD for a while, and so functional interfaces appeal to me.

This is a key part of what our software needs to be able to do, and I suspect that it's not an uncommon requirement.

[franciscave]

I'm trying to think RESTfully about this. Trying to generalise the problem, what one wants is a report on the validity of the entity in question, in this case a patron entity. So one could request creation of a validity report on an entity using a POST containing the entity whose validity you want checked. I suspect that this isn't a truly RESTful approach, but if not, what is the right approach?

[mdovey]

We discussed this over coffee on Tuesday, and whilst this is a nice simple solution, it places a lot of trust on the client.

i.e. the client is responsible for checking the validity of the pin before issuing a check-out, and not requesting a check-out if the pin is invalid. However, a malicious client could still request a check-out regardless of the pin validity and the server would still process the check-out (as the check-out request is independent of the validity report request).

This approach would work for some use cases e.g. the self issue kiosk where the client and server are within the same trust domain, or in simple user validation (where no other LCF features are used), but would not work for many other use cases.

[MarkOliver]

There already is a lot of responsibility on the client if operations can be conducted, for example checking out a book, without a valid patron id and PIN. Even reading of patron data carries with it responsibility. Adding in new functionality to explicitly check for PIN validity doesn't really affect that.

The solution that I develop has the requirement for simple user validation, and this requirement is met by SIP2.

The current REST specification suggest that user-id (Q00D01.2) and user-pwd (Q00D02.2) could be added to the request entity URI. And if that were implemented then it could work, but the other discussion suggests that this is insecure and that the password should really be provided in the encrypted body of a PUT or POST request.

This means that if there were no explicit "check this PIN code" web service I would have to request an entity and then issue an update, with no changes to the data, and rely on the web server giving me back an error code if the password were incorrect.

This would work, but it seems a little clunky. And the idea of issuing updates just to verify PIN correctness seems worryingly powerful.

But, that said, having an explicit "verify" service does move the interface away from being just CRUD to being also about logical operations, and maybe people don't want to go there.

[mdovey]

I'm not sure I fully agree with your initial comment. I can't see how (or why) server would permit a checkout to a unknown patron, and whether it allows checkout without a valid pin is a server configuration issue.

Moreover if validating both patron id and pin is important - this should always be done at the server end! Doing it at the client end would break any security audit!

in terms of the security of passing the user-id and user-pwd on the URI - when using https the request part of the URI (i.e. the part after https://server ) is sent over the same encrypted channel as the body of the message. There is a good overview here:

https://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/

As noted in that blog there are three potential caveats, in reverse order:

(3) referral headers doesn't really apply to REST\webservices unless someone perhaps is writing a javascript client (but that javascript client can do other bad stuff with the username\password)

(2) bookmarks, doesn't apply to REST\webservices (apart from a developer testing things)

(1) is a server configuration issue (and there is nothing to stop someone from configuring a server to also log HTTP headers or body)

However, an alternative approach if URL query params are perceived to be less secure than they perhaps are, might be some user defined custom HTTP request headers e.g.

X-LCF-User-Id
X-LCF-User-Pwd

in the existing messages?

[MarkOliver]

Yes the validation of patron ID and PIN should be done at the server end, the question is how this should be done when the client will not be performing any other operation other than GETting the patron details.

If the questions raised in the other issue about providing user ID and PIN in the URL are seen as not being a great issue then providing them in that GET request wouldn't be an issue at all. Providing the patron credentials as custom headers would also be OK from my point of view.

A solution would be for the patron credentials to be optional on GET requests (some times a client will need to get a patron's details without knowing their PIN) but if user-id and user-pwd (either in the URL or with custom headers, whichever method is preferred) are provided the server should validate them and return a 401 if they are wrong.

[anthonywhitford]

While we were at the PlugFest this idea was discussed somewhat. The outcome we came to at that point was to introduce the GET request for Patron authorisations, which would allow the caller to be told by the LMS/ILS what the Patron was permitted to do.

If we want to assess whether a Patron BARCODE & PIN are a valid combination, performing a GET for an authorisation token meets that, since the token would not be provided if the BARCODE & PIN were invalid. The authorisation token could be safely encrypted and used as a substitute for the BARCODE & PIN where the Patron needed to be identified by the LMS, for example issuing a book.

This would also introduce a greater level of security, since the authorisation token could be encrypted, not contain the PIN and also be time sensitive, so it would expire.

If we wanted to extend the discussion (perhaps on a different thread) this would align with the use of OAUTH2 for authorising the self-service terminal, and the Patron using similar processes.

[colinparkeruk]

+1 for the use of a token. This would suit Single Sign On scenarios, e.g. a portal where a user signs on once for access to their Facebook, Twitter, LMS, etc. and also privileged LMS staff access to patron's details.

[MarkOliver]

+1 for the use of a token (but I think it should be a POST and not a GET).

[anthonywhitford]

The LCF Technical Editors, and developers from Bibliotheca and Capita held a call on 5th May 2016 where we concluded that OpenID Connect appears to be a viable option for secure token based authentication within the use cases for LCF.

We agreed that we should higlight this with the LCF Review Panel at the next meeting, and given suitable resource from Bibliotheca and Capita, that a small proof of concept would be constructed. This would allow demonstration of whether OpenID Connect would serve as an appropriate authentication solution covering both the Kiosk only authentication and the Kiosk with Patron authentication required for issuing library items.

[franciscave]

This was discussed briefly at the Technical Panel meeting on 28 June. The Technical Panel is happy with the proposal to create a proof of concept, which will inform how to document the use of OAuth / OpenID Connect in the LCF web service specification in due course.

[franciscave]

My understanding of what was agreed at the Review Group meeting on 22 February 2018 is that, given that a more sophisticated authentication mechanism using third party authentication servers will not be in place for some while, we will in the meantime provide a solution to this issue in line with what has been proposed in Issue 55, i.e. enabling the patron's identity to be verified by the LMS.

[anthonywhitford]

Discussion in the Technical Panel meeting on 2018-05-02 agreed that the authentication and authorisation work was now correctly specified and this issue can be closed.