Clarification on Access control for LCF Entities

[anthonywhitford]

While investigating LCF Issue 328 and attempting a PoC for verification of the core functions for the Patron entity using the ceridwen reference implementation, I had an issue retrieving individual Patron records. The list function works as expected, however, the individual GET for a specific record fails with a HTTP/403 Forbidden message.

The LCF standard describes authentication and authorisation here in bullet point 1 as:

GET /lcf/1.0/patrons/{id-value}
Authorization: BASIC {Base64-encoded-terminal-credentials}

where {Base64-encoded-terminal-credentials} is constructed from elements Q00D04.2 and Q00D05.2 (see [4]).

Elements Q00D04.2 and Q00D05.2 defined here are the Terminal ID and Terminal Password.

Checking within application authentication bullet point 2 there is a subtly different example:

GET /lcf/1.0/patrons/{id-value}
lcf-patron-credential: BASIC {Base64-encoded-patron-credentials}

Checking further within bullet point 4, there is another example where Patron Authorisations are being retrieved, which requires both terminal and patron authentication.

GET /lcf/1.0/patrons/{id-value}/authorisations
Authorization: BASIC {Base64-encoded-terminal-credentials}=
lcf-patron-credential: BASIC {Base64-encoded-patron-credentials}

These three scenarios introduce a lack of clarity, which the documentation has attempted to resolve in bullet point 3, by invoking the requests and trying credentials based on the response, however, this leaves the standard open to interpretation.

Is it correct that the terminal authentication can be absent from certain requests if the patron authentication is present?

Can we update the standard to indicate which entities or functions should require which authentication tokens to be provided?

What is "correct" and therefore enforceable as part of Issue #328 ?

[franciscave]

Good questions! It's a while since we last discussed terminal and patron authentication (these were added in v1.2.0, which was published in December 2019). My assumption has been that requirements for terminal and patron authentication are independent of one another, so neither, either or both might be required by a specific implementation. Whether I'm right or not - and I admit this isn't an area where I have particular expertise - I agree that the intention isn't clearly stated in the documentation. But I think that the use of the three cases in the examples was deliberate: we didn't want to imply that some particular combinations of terminal and patron authentication were mandated by the standard, which might have been the implication if they were all the same.

I think it would be helpful to introduce an endnote, with pointers to it from the examples in implementation notes 1, 2 and 3, making it clear that it is an implementation choice and to what permutations of terminal and patron authentication (including none) are required, according to the type of request being made.

[anthonywhitford]

Hi Francis, Thanks for your reply. Based on my experience, the terminal application authentication would be required for all requests, and the patron authentication would only be provided in addition. My basis for this is the terminal application authentication ensures the connection can be established and we trust the caller making the request. The addition of patron authentication would only be required where a patron specific operation was being performed, such as modifying their data or making a transaction on their behalf.

As it stands, I don't think we can validate the Core LMS function profile (which is essentially 'read all entities') without knowing the Patron identity and password/pin for many (or all) Patrons within the system.