| Summary: | No permissions SSO login to staff client should redirect to a custom URL | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Alex Buckley <alexbuckley> |
| Component: | Authentication | Assignee: | Alex Buckley <alexbuckley> |
| Status: | CLOSED INVALID | QA Contact: | Testopia <testopia> |
| Severity: | enhancement | ||
| Priority: | P5 - low | CC: | dcook, dpavlin |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | Sponsored | Comma delimited list of Sponsors: | |
| Crowdfunding goal: | 0 | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
| Attachments: | Bug 23930: Implemented syspref where you can configure URL re-directed to whena patron with insufficient permissions tries to login to the staff client | ||
|
Description
Alex Buckley
2019-10-30 22:55:53 UTC
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 |