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

[Mike Rylander]

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.

Thoughts?  Anyone with tuits?

Thanks.


--
Mike Rylander
 | President
 | Equinox Open Library Initiative
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at equinoxinitiative.org
 | web:  http://equinoxinitiative.org

On Thu, Dec 7, 2017 at 5:27 PM, Josh Stompro <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#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
> <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>
> *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 <(218)%20233-3757>
>
> LARL IT Director | Cell 218.790.2110 <(218)%20790-2110>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20171211/245c894a/attachment.html>