[Koha-bugs] [Bug 23930] No permissions SSO login to staff client should redirect to a custom URL

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23930

Alex Buckley <alexbuckley at catalyst.net.nz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|ASSIGNED                    |RESOLVED

--- Comment #5 from Alex Buckley <alexbuckley at catalyst.net.nz> ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.