[OPEN-ILS-GENERAL] SIP2 - Block certain patrons from authenticating for a particular login - Evergreen End

[Josh Stompro]

I think I found a way to hard code this sort of check into sipserver, once I found the correct spot to look.

At the following locations I just added a check to not allow certain combinations of sip login accounts and patron types.  This seems to short circuit the login check/info check correctly, just for the services that we want to restrict.

http://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=Sip/MsgType.pm;h=bd7cb521beeda53787a64264a0f75a4364285d11;hb=HEAD#l458

http://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=Sip/MsgType.pm;h=bd7cb521beeda53787a64264a0f75a4364285d11;hb=HEAD#l1001

The patron type and login username was readily available.

if ($patron && !($server->{account}='SIP_MNLINK' && $patron->ptype =~ m/LARL Temporary|LARL ND Reciprocal|LARL Fee|LARL ILL/)) {

I love evergreen!  And thanks to wolfram alpha for building me a truth table to make sure I had the logic correct.
https://www.wolframalpha.com/input/?i=P+and+not+(+Q+and+Z+)

Josh Stompro - LARL IT Director

From: Open-ils-general [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Josh Stompro
Sent: Thursday, December 07, 2017 2:20 PM
To: Evergreen Discussion Group <open-ils-general at list.georgialibraries.org>
Subject: Re: [OPEN-ILS-GENERAL] SIP2 - Block certain patrons from authenticating for a particular login - Evergreen End


This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing>

Feedback<http://aka.ms/SafetyTipsFeedback>

I just realized that I was wrong about the patron info response not including the patron type, it does include it in the PC message, but I think it would still be nice to do this server side in some cases.

Josh Stompro - LARL IT Director

From: Open-ils-general [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Josh Stompro
Sent: Thursday, December 07, 2017 11:47 AM
To: 'Evergreen Discussion Group' <open-ils-general at list.georgialibraries.org<mailto:open-ils-general at list.georgialibraries.org>>
Subject: [OPEN-ILS-GENERAL] SIP2 - Block certain patrons from authenticating for a particular login - Evergreen End


This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing>

Feedback<http://aka.ms/SafetyTipsFeedback>

Hello, Has anyone come up with a way of controlling authentication via sip2 on the sip2 server side for particular users or types of users?

We have various different services that authenticate via sip2, such as our patron management (cassie), Overdrive, and our state ILL system (MNLINK).  The problem we are running into is that certain user groups (permission groups) shouldn't be able to access some of those services.

For example, we have temporary users that have more limited capabilities since we cannot fully verify their info, or their residence status is in flux.  We don't want those patrons to be able to request material from other libraries, but we do want them to be able to access public computers and overdrive.

The patron permission group doesn't seem like it is something that is sent in the patron status response to the vendors, so I don't think there is a way for them to check it on their end.  And it seems like it would be more fool proof to handle it on the server side, not trusting a vendor to take care of something.

When we used the III patron API product the info was sent to the vendor (basically the entire patron record was sent which wasn't great), but it did take care of this issue for us.

I'm wondering if something along the lines of a custom permission would work.  Only allow users in a certain group to authenticate through a certain sip2 connection (identified by the sip2 login).   So a patron had the permission SIP_AUTH_SIP_MNLINK allow their barcode to authenticate.  This would probably also require a library setting to make it opt in since there would be setup required.

Alternatively, add a standing penalty that includes a block in the form |SIP_AUTH_SIP_MNLINK to block authentication for those patrons.  And then make sure we always add that block for users that we don't want.  Then we could add the penalty manually or with a nightly query.  The SIP code would look for a block in that form and deny auth if it shows up.

I've been looking at Open-ILS/src/perlmods/lib/OpenILS/SIP/Patron.pm to see how ether of these might fit in.  I'm not quite sure if the sip2 connection username is available to that code though.  I'll keep looking.


Thanks
Josh

Lake Agassiz Regional Library - Moorhead MN larl.org
Josh Stompro     | Office 218.233.3757 EXT-139
LARL IT Director | Cell 218.790.2110

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20171207/f0a4132f/attachment.html>