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-boun...@list.georgialibraries.org] On Behalf Of Josh 
Stompro
Sent: Thursday, December 07, 2017 11:47 AM
To: 'Evergreen Discussion Group' <open-ils-general@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

Reply via email to