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

Mon Dec 11 15:37:15 EST 2017

On 12/11/2017 01:06 PM, Mike Rylander wrote:
> Josh,
> 
> It might be better added this to the Evergreen driver, which is
> ILS-aware, to avoid pain down the road when SipServer eventually
> changes.  It could be driven (heh) by an <implementation_config> chunk
> in the config file, or perhaps as a new attribute on the <login> element
> (where $server->{account} comes from, IIRC).  This could list one or
> more permissions required for patron authz.  The driver could then test
> for those permissions, and if the patron does not have any of them (or
> maybe all of them, or, perhaps, any/all based on different config
> locations), the authz request fails.

I mostly agree, though I'd like to see SIPServer merged into Evergreen
at this point. It's not compatible with Koha's SIPServer any more, so no
real point in keeping it as a separate project.

Ditto NCIPServer. It became incompatible with Koha pretty much as soon
as I started working on it.

> 
> Thoughts?  Anyone with tuits?
> 
> Thanks.
> 
> 
> --
> Mike Rylander
>  | President
>  | Equinox Open Library Initiative
>  | phone:  1-877-OPEN-ILS (673-6457)
>  | email:  miker at equinoxinitiative.org <mailto:miker at equinoxinitiative.org>
>  | web:  http://equinoxinitiative.org
> 
> On Thu, Dec 7, 2017 at 5:27 PM, Josh Stompro <stomproj at exchange.larl.org
> <mailto:stomproj at exchange.larl.org>> wrote:
> 
>     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#l458>____
> 
>     __ __
> 
>     http://git.evergreen-ils.org/?p=SIPServer.git;a=blob;f=Sip/MsgType.pm;h=bd7cb521beeda53787a64264a0f75a4364285d11;hb=HEAD#l1001
>     <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+)
>     <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
>     <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
>     <mailto: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
>     <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
>     <http://larl.org>____
> 
>     Josh Stompro     | Office 218.233.3757 EXT-139
>     <tel:(218)%20233-3757>____
> 
>     LARL IT Director | Cell 218.790.2110 <tel:(218)%20790-2110>  ____
> 
>     __ __
> 
> 