SIP2 admits existence of barred patrons

[Thomas Berezansky]

I am reporting this as a security issue because I have no idea how much of a problem others will consider this. I personally have no issue if we decide this can be switched to a non-security state.

open-ils.auth treats "Barred" patrons as being the same as "Deleted" patrons. As in, it does not admit they exist in any way, as though the row doesn't exist in the table. Inactive users may be thrown out with an event stating they are inactive instead of being treated as though they don't exist, but still aren't allowed in as far as I know.

The SIP2 perl modules, on the other hand, do not admit deleted or inactive users exist, but have no problem with barred users. They will say "they aren't allowed to do anything" and set a screen message of "barred" but that is about it. Other checks, including (as far as I have been able to tell) validating the user's password, go on without issue. As such, if something (say, an electronic database vendor's system) asks if a card exists, but doesn't check/care about the "can they check stuff out" flags, the card will come back as valid when barred.

I personally think that if open-ils.auth won't even admit a barred patron exists that SIP2 should probably do the same thing.

[Galen Charlton (gmc)]

Bug 1010671 provides some historical context.

Gut reaction: I'd argue that in some circumstances, it's OK for SIP2 clients to treat the barred status differently from the deleted condition. In particular, if a patron is using a self-checkout device in the library, having it be able to tell the patron that their library privileges have been suspended would be useful.

I also think it's reasonable to treat SIP2 requests for eresource authentication differently.

So to continue my gut reaction: this smells like a reason to add a new SIP config option to specify whether or not SIP2 requests treat barred patrons as if they exist or not, allowing for a library to treat self-check devices one way and resource authentication another.

[Galen Charlton (gmc)]

After review by the security team, we've agreed that this bug does not represent a security issue and are changing its visibility to "public".