Bug 26912 - Expired staff accounts can still log in to Koha staff intranet, SIP, API, etc.
Summary: Expired staff accounts can still log in to Koha staff intranet, SIP, API, etc.
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-03 15:48 UTC by Kyle M Hall
Modified: 2024-01-03 19:34 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2020-11-03 15:48:01 UTC
We just discovered that staff accounts can be used for staff logins, SIP, API, etc even if they are expired. The question we don't have an answer to is; should this be allowed?

We could prevent staff logins for expired accounts, or perhaps add a new 'enabled' column to explicitly enable/disable accounts from logging in to Koha. 

Right now, the only way to disable an account without deleting it is to remove user permissions, which may be non trivial if the account has complicated permissions and may need to be 'restored' in the future.

What do you all think?
Comment 1 Didier Gautheron 2020-11-03 19:07:42 UTC
Hi,

Isn't changing password good enough?

Doing it the Unix way , with an invalid password should be better though.
Comment 2 Katrin Fischer 2020-11-03 21:44:30 UTC
A changed password can't be queried, I like the idea of an enable/disable functionality for the permissions. You would still want to allow OPAC logins, but  block staff.
Comment 3 David Cook 2020-11-04 00:05:31 UTC
Locally, I think that we block all expired users from logging in. 

We do already have the "debarred" column. We use that for some local customizations too where we want to block people from logging in.
Comment 4 David Cook 2020-11-04 00:06:04 UTC
(In reply to David Cook from comment #3)
> Locally, I think that we block all expired users from logging in. 
> 
> We do already have the "debarred" column. We use that for some local
> customizations too where we want to block people from logging in.

Although I suppose being debarred until 9999-12-31 isn't exactly the same as "disabled" heh.
Comment 5 David Cook 2020-11-04 00:08:27 UTC
(In reply to Katrin Fischer from comment #2)
> A changed password can't be queried, I like the idea of an enable/disable
> functionality for the permissions. You would still want to allow OPAC
> logins, but  block staff.

We could query it if we changed the password field to "!". I feel that's something that Koha sometimes does?
Comment 6 Kyle M Hall 2020-11-04 12:12:35 UTC
(In reply to David Cook from comment #5)
> (In reply to Katrin Fischer from comment #2)
> > A changed password can't be queried, I like the idea of an enable/disable
> > functionality for the permissions. You would still want to allow OPAC
> > logins, but  block staff.
> 
> We could query it if we changed the password field to "!". I feel that's
> something that Koha sometimes does?

I'm not seeing the in the code with some basic grepping. The problem I see with that is, again, that it changes data about the user. The user's password is then lost, and without additional data ( public note, private note ), the reason for the password being changed would be unknown.
Comment 7 David Cook 2020-11-04 23:36:43 UTC
(In reply to Kyle M Hall from comment #6)
> (In reply to David Cook from comment #5)
> > (In reply to Katrin Fischer from comment #2)
> > > A changed password can't be queried, I like the idea of an enable/disable
> > > functionality for the permissions. You would still want to allow OPAC
> > > logins, but  block staff.
> > 
> > We could query it if we changed the password field to "!". I feel that's
> > something that Koha sometimes does?
> 
> I'm not seeing the in the code with some basic grepping. The problem I see
> with that is, again, that it changes data about the user. The user's
> password is then lost, and without additional data ( public note, private
> note ), the reason for the password being changed would be unknown.

Hmm maybe that's something from the past then. I thought we used to set the password field to ! when we didn't have a password for users. Or maybe that's something we did locally...

But I agree about the reasons not to do it.
Comment 8 gclg 2021-01-26 14:15:59 UTC
This badly needs a restriction on accounts for Koha access via the staff client.  At the moment the only option would appear to be removing the ability to log in from the the permissions. 

The ability to restrict access based on Patron Category would be the preferred option.
Comment 9 Ray Delahunty 2021-11-17 10:27:12 UTC
We use external authentication rather than using Koha authentication so if the removal of access were to be based on the Koha password, that would not work for us.
Comment 10 gclg 2021-11-17 11:06:55 UTC
Perhaps the option to temporary restrict accounts which access the staff client would the preferred priority.

There are probably numerous requirements for non Library staff/patrons which would be almost impossible to standardise. 

As mentioned the only way around limiting accounts which access the client is to remove the ability to log in via the permissions. I'd be interested to see where this sits with Cyber Essentials/internal auditing.
Comment 11 David Cook 2021-11-17 22:42:26 UTC
(In reply to Ray Delahunty from comment #9)
> We use external authentication rather than using Koha authentication so if
> the removal of access were to be based on the Koha password, that would not
> work for us.

That's a good point.
Comment 12 David Cook 2022-11-02 01:39:09 UTC
If I recall correctly, locally we block SIP logins if the user is expired.

So I think this could actually just be handled during an authorization step. 

We just need to add some business logic alongside the account lockout feature I imagine.
Comment 13 David Cook 2022-11-02 01:40:09 UTC
(In reply to David Cook from comment #12)
> So I think this could actually just be handled during an authorization step. 

That is, they've proven they are who they say they are during the authentication step.

But expired users aren't authorized to use Koha, so they must take steps out-of-band to no longer be expired, so that they can be re-authorized.