Presently if a patron tries to login to the staff client and they have insufficient permissions they are re-directed back to the Koha login page with the message: 'Error: You do not have permissions to access this page'. This is fine when the staff client authentication is the native Koha login, but when you have a SSO implemented then logging in via the Koha login page and then being re-directed to a native koha login form does not make sense. We'd like to implement a syspref InsufficientPermissionRedirectURL which the staff client re-directs to if the authenticating patron does not have permission to view the staff client.
Created attachment 94894 [details] [review] Bug 23930: Implemented syspref where you can configure URL re-directed to whena patron with insufficient permissions tries to login to the staff client Sponsored-by: Waikato Institute of Technology, New Zealand
Hi Alex, should this be updated (has a patch, but is Assigned)
Hi Katrin, Thanks for noting that. I am not happy with my initial patchfix for this so am going to remove it and start again on a fix for this. Thanks, Alex
I'm not sure that I understand this one. What SSO are you targeting and what scenario? From the OPAC side, I have a OpenID Connect client for Koha (which one of these days I'll find time to upstream). If I already have a session with the Identity Provider and I click on a Koha link, it'll prompt me to log in, I'll choose my Identity Provider from the login options for Koha, it'll bounce me to the IdP, then bounce me back. If I don't have authorization/permission, I'd expect to see my original Koha page saying that I'm not authorized. I could see it being an issue if it re-directed me to a login page though, as I'd already be authenticated just not authorized... ...which is where I'm getting lost with your description. You're saying the patron has been authenticated but they're not authorized to be in the staff client, so they're being re-directed to the Koha login page instead of whatever page they were trying to access? I take it that you want to redirect the patron back to the page they were on before they navigated to Koha? What kind of SSO is this? I'm guessing the redirection to the IdP must be automatic and not require the user to click on something on the Koha staff client login side?
Hi David(In reply to David Cook from comment #4) > I'm not sure that I understand this one. > > What SSO are you targeting and what scenario? > > From the OPAC side, I have a OpenID Connect client for Koha (which one of > these days I'll find time to upstream). If I already have a session with the > Identity Provider and I click on a Koha link, it'll prompt me to log in, > I'll choose my Identity Provider from the login options for Koha, it'll > bounce me to the IdP, then bounce me back. If I don't have > authorization/permission, I'd expect to see my original Koha page saying > that I'm not authorized. > > I could see it being an issue if it re-directed me to a login page though, > as I'd already be authenticated just not authorized... > > ...which is where I'm getting lost with your description. > > You're saying the patron has been authenticated but they're not authorized > to be in the staff client, so they're being re-directed to the Koha login > page instead of whatever page they were trying to access? > > I take it that you want to redirect the patron back to the page they were on > before they navigated to Koha? > > What kind of SSO is this? I'm guessing the redirection to the IdP must be > automatic and not require the user to click on something on the Koha staff > client login side? Hi David, We were using Mod_mellon and SAML, and yes once the user had been authenticated they were automatically re-directed to the Koha login page instead of whatever page they were trying to access. However, we've since shifted to using Shibboleth for implementing SSO so I think we can now close this bug report, as it is no longer redundant. Thanks, Alex