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

[Jason Stephenson]

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  chunk
> in the config file, or perhaps as a new attribute on the  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:  mi...@equinoxinitiative.org 
>  | web:  http://equinoxinitiative.org
> 
> On Thu, Dec 7, 2017 at 5:27 PM, Josh Stompro  > 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-boun...@list.georgialibraries.org
> ] *On
> Behalf Of *Josh Stompro
> *Sent:* Thursday, December 07, 2017 2:20 PM
> *To:* Evergreen Discussion Group
>  >
> *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
> 
> 
>   
> 
> Feedback 
> 
> 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'
>  >
> *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
> 
> 
>   
> 
> Feedback 
> 
> Hello, Has anyone come up with a way of controlling authentication
> via sip2 on the sip2 server side for particular users or types of
> 

Re: [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  chunk in the config file, or
perhaps as a new attribute on the  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:  mi...@equinoxinitiative.org
 | web:  http://equinoxinitiative.org

On Thu, Dec 7, 2017 at 5:27 PM, Josh Stompro <stomp...@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-
> boun...@list.georgialibraries.org] *On Behalf Of *Josh Stompro
> *Sent:* Thursday, December 07, 2017 2:20 PM
> *To:* Evergreen Discussion Group <open-ils-general@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-
> boun...@list.georgialibraries.org
> <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 w

Re: [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-boun...@list.georgialibraries.org] On Behalf Of Josh 
Stompro
Sent: Thursday, December 07, 2017 2:20 PM
To: Evergreen Discussion Group <open-ils-general@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-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<mailto: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

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

[Josh Stompro]

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' 
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

Feedback

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