|
Description
Alex Buckley
2022-04-04 03:47:56 UTC
Created attachment 133419 [details] [review] Bug 30444: Add shibboleth login to self checkout This patch adds a 'Shibboleth' option to the SelfCheckoutByLogin system preference. When 'Shibboleth' is selected the user should be logged straight into the self check module - assuming the AutoSelfCheckAllowed, AutoSelfCheckID and AutoSelfCheckPass system preferences are set. Test plan: 1. Have your Koha setup to do Shibboleth login 2. Set the following system preferences: - AutoSelfCheckAllowed => 'Allow' - AutoSelfCheckId and AutoSelfCheckPass => Set these to a patron with 'circulate' permissions - WebBasedSelfCheck -> 'Enable' - OpacShibOnly -> "Don't allow" 3. Visit the self checkout page /cgi-bin/koha/sco/sco-main.pl and notice a local login page loads 4. Apply patchset, update database and restart services 5. Set the new syspref: - SelfCheckoutByLogin -> 'Shibboleth' 6. Visit the self checkout page and notice you're logged into the sco interface straight away, without the local login page loading Sponsored-by: Catalyst IT Created attachment 133512 [details] [review] Bug 30444: Add shibboleth login to self checkout This patch adds a 'Shibboleth' option to the SelfCheckoutByLogin system preference. When 'Shibboleth' is selected the user should be logged straight into the self check module - assuming the AutoSelfCheckAllowed, AutoSelfCheckID and AutoSelfCheckPass system preferences are set. Test plan: 1. Have your Koha setup to do Shibboleth login 2. Set the following system preferences: - AutoSelfCheckAllowed => 'Allow' - AutoSelfCheckId and AutoSelfCheckPass => Set these to a patron with 'circulate' permissions - WebBasedSelfCheck -> 'Enable' - OpacShibOnly -> "Don't allow" 3. Visit the self checkout page /cgi-bin/koha/sco/sco-main.pl and notice a local login page loads 4. Apply patchset, update database and restart services 5. Set the new syspref: - SelfCheckoutByLogin -> 'Shibboleth' 6. Visit the self checkout page and notice you're logged into the sco interface straight away, without the local login page loading Sponsored-by: Catalyst IT Created attachment 133513 [details] [review] Bug 30444: Add shibboleth login to self checkout This patch adds a 'Shibboleth' option to the SelfCheckoutByLogin system preference. When 'Shibboleth' is selected the user should be logged straight into the self check module - assuming the AutoSelfCheckAllowed, AutoSelfCheckID and AutoSelfCheckPass system preferences are set. Test plan: 1. Have your Koha setup to do Shibboleth login 2. Set the following system preferences: - AutoSelfCheckAllowed => 'Allow' - AutoSelfCheckId and AutoSelfCheckPass => Set these to a patron with 'circulate' permissions - WebBasedSelfCheck -> 'Enable' - OpacShibOnly -> "Don't allow" 3. Visit the self checkout page /cgi-bin/koha/sco/sco-main.pl and notice a local login page loads 4. Apply patchset, update database and restart services 5. Set the new syspref: - SelfCheckoutByLogin -> 'Shibboleth' 6. Visit the self checkout page and notice you're logged into the sco interface straight away, without the local login page loading Sponsored-by: Catalyst IT Created attachment 133518 [details] [review] Bug 30444: Add shibboleth login to self checkout This patch adds a 'Shibboleth' option to the SelfCheckoutByLogin system preference. When 'Shibboleth' is selected the user should be logged straight into the self check module - assuming the AutoSelfCheckAllowed, AutoSelfCheckID and AutoSelfCheckPass system preferences are set. Test plan: 1. Have your Koha setup to do Shibboleth login 2. Set the following system preferences: - AutoSelfCheckAllowed => 'Allow' - AutoSelfCheckId and AutoSelfCheckPass => Set these to a patron with 'circulate' permissions - WebBasedSelfCheck -> 'Enable' - OpacShibOnly -> "Don't allow" 3. Visit the self checkout page /cgi-bin/koha/sco/sco-main.pl and notice a local login page loads 4. Apply patchset, update database and restart services 5. Set the new syspref: - SelfCheckoutByLogin -> 'Shibboleth' 6. Visit the self checkout page and notice you're logged into the sco interface straight away, without the local login page loading Sponsored-by: Catalyst IT Still doing some testing of this patchset locally. Created attachment 133614 [details] [review] Bug 30444: Add shibboleth login to self checkout This patch adds a 'Shibboleth' option to the SelfCheckoutByLogin system preference. When 'Shibboleth' is selected the user should be logged straight into the self check module - assuming the AutoSelfCheckAllowed, AutoSelfCheckID and AutoSelfCheckPass system preferences are set. Test plan: 1. Have your Koha setup to do Shibboleth login 2. Set the following system preferences: - AutoSelfCheckAllowed => 'Allow' - AutoSelfCheckId and AutoSelfCheckPass => Set these to a patron with 'circulate' permissions - WebBasedSelfCheck -> 'Enable' - OpacShibOnly -> "Don't allow" 3. Visit the self checkout page /cgi-bin/koha/sco/sco-main.pl and notice a local login page loads 4. Apply patchset, update database and restart services 5. Set the new syspref: - SelfCheckoutByLogin -> 'Shibboleth' 6. Visit the self checkout page and notice you're logged into the sco interface straight away, without the local login page loading Sponsored-by: Catalyst IT Created attachment 133615 [details] [review] Bug 30444: Add shibboleth login to self checkout This patch adds a 'Shibboleth' option to the SelfCheckoutByLogin system preference. When 'Shibboleth' is selected the user should be logged straight into the self check module - assuming the AutoSelfCheckAllowed, AutoSelfCheckID and AutoSelfCheckPass system preferences are set. Test plan: 1. Have your Koha setup to do Shibboleth login 2. Set the following system preferences: - AutoSelfCheckAllowed => 'Allow' - AutoSelfCheckId and AutoSelfCheckPass => Set these to a patron with 'circulate' permissions - WebBasedSelfCheck -> 'Enable' - OpacShibOnly -> "Don't allow" 3. Visit the self checkout page /cgi-bin/koha/sco/sco-main.pl and notice a local login page loads 4. Apply patchset, update database and restart services 5. Set the new syspref: - SelfCheckoutByLogin -> 'Shibboleth' 6. Visit the self checkout page and notice you're logged into the sco interface straight away, without the local login page loading Sponsored-by: Catalyst IT Created attachment 133616 [details] [review] Bug 30444: (follow-up) WIP: Don't re-direct infinite loop if SelfCheckoutByLogin not equal to 'shibboleth' Test plan: 1. On a Koha setup to do Shibboleth set the following sysprefs: - OPACShibOnly = "Don't allow" - AutoSelfCheckAllowed = Allow - AutoSelfCheckID and AutoSelfCheckPass = The username and password of a patron with 'self_checkout_module' sub-permission enabled - SelfCheckoutByLogin = 'cardnumber' 2. Visit the self checkout page, confirm it does not indefinitely loop 3. Change SelfCheckoutbyLogin = 'username and password' 4. Repeat step 2 and confirm the same results 5. Change SelfCheckoutByLogin = 'shibboleth' 6. Repeat step 2 and confirm the same results Sponsored-by: Catalyst IT Created attachment 134007 [details] [review] Bug 30444: (follow-up) WIP: Don't re-direct infinite loop if SelfCheckoutByLogin not equal to 'shibboleth' Test plan: 1. On a Koha setup to do Shibboleth set the following sysprefs: - OPACShibOnly = "Don't allow" - AutoSelfCheckAllowed = Allow - AutoSelfCheckID and AutoSelfCheckPass = The username and password of a patron with 'self_checkout_module' sub-permission enabled - SelfCheckoutByLogin = 'cardnumber' 2. Visit the self checkout page, confirm it does not indefinitely loop 3. Change SelfCheckoutbyLogin = 'username and password' 4. Repeat step 2 and confirm the same results 5. Change SelfCheckoutByLogin = 'shibboleth' 6. Repeat step 2 and confirm the same results Sponsored-by: Catalyst IT Created attachment 134199 [details] [review] Bug 30444: (follow-up) Ensure Self checkout by cardnumber and username/password works Test plan: 1. On a Koha setup to do Shibboleth set the following sysprefs: - OPACShibOnly = "Don't allow" - AutoSelfCheckAllowed = Allow - AutoSelfCheckID and AutoSelfCheckPass = The username and password of a patron with 'self_checkout_module' sub-permission enabled - SelfCheckoutByLogin = 'cardnumber' 2. Visit the self checkout page. Confirm a 'cardnumber' input page is loaded 3. Enter a cardnumber and confirm the self checkout page loads 4. Change SelfCheckoutbyLogin = 'username and password' 5. Repeat step 2 and confirm a username and password input page loads. 6. Enter a username and password and confirm the self checkout page loads 7. Change SelfCheckoutByLogin = 'shibboleth' 8. Repeat step 2 and confirm you're logged straight into the self checkout Sponsored-by: Catalyst IT This is interesting. I'll need to review the shibboleth code here. I haven't tested this yet, but after reviewing the code... I can't wrap my head around how this is supposed to work. Typically, when you visit http://localhost:8080/cgi-bin/koha/sco/sco-main.pl, the AutoSelfCheckAllowed will create an authenticated user session using AutoSelfCheckID and AutoSelfCheckPass. Then, you either provide a cardnumber or a username/password to move on to the actual self-checkout, but that cardnumber or username/password doesn't create a "session". Looking at these patches, why would an external Shibboleth login be triggered? I see at https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=30444&attachment=133615 that it says "Do Shibboleth login" but it doesn't do a Shibboleth login. Rather, it just gets the Shibboleth details out of the environmental variables. That assumes that you've already been redirected to a SAML IdP and been returned back to Koha. The only way it could work is if you logged into Koha using a SAML IdP and then visited the self-checkout, which would bypass the AutoSelfCheckAllowed handling because Koha privileges an existing session (supplied by CGISESSID cookie) above all else. But maybe I'm missing something. Could you detail the exact workflow here? Also, what happens when you click "Finish"? The external IdP session will still be valid, so whatever triggers the Shibboleth login will automatically log you back in again next time, since there's no logout handling here? I'm interested in getting this working, but the only way I can think of it working would be to have a "Shibboleth" login button that you press in the Self-Checkout, get redirected to SAML IdP, log in, get redirected back to the self-checkout which can use the HTTP_ environmental variables to get the SSO details. Then either on timeout or on "Finish" click, there would need to be a logout call back to the SAML IdP. At least this would be necessary on a public terminal. Hi David, Thank you for your questions and my apologies for my late reply. The exact workflow we are wanting to follow with this patchset is: 1. A patron logs into the OPAC via SSO shibboleth 2. They visit the self-checkout page 3. As Koha is configured with AutoSelfCheckAllowed = allowed, and AutoSelfCheckId and AutoSelfCheckPass set to a patron with 'circulate' permissions that patron is used to automatically authenticate to the self-checkout page 4. Instead of displaying a form asking for the identity (username/password or cardnumber) of the patron we want to check out to, our patch skips that form by identifying the person logged into the OPAC as the patron to check out to So in short, the only difference in behaviour our patchset should have is skipping the form asking for the identity of the patron we want to checkout too. Does this help clarify the intent? Thanks, Alex (In reply to Alex Buckley from comment #15) > Hi David, > > Thank you for your questions and my apologies for my late reply. > > The exact workflow we are wanting to follow with this patchset is: > > 1. A patron logs into the OPAC via SSO shibboleth > > 2. They visit the self-checkout page > > 3. As Koha is configured with AutoSelfCheckAllowed = allowed, and > AutoSelfCheckId and AutoSelfCheckPass set to a patron with 'circulate' > permissions that patron is used to automatically authenticate to the > self-checkout page > > 4. Instead of displaying a form asking for the identity (username/password > or cardnumber) of the patron we want to check out to, our patch skips that > form by identifying the person logged into the OPAC as the patron to check > out to > > So in short, the only difference in behaviour our patchset should have is > skipping the form asking for the identity of the patron we want to checkout > too. > > Does this help clarify the intent? Thanks, Alex. That does clarify things a bit. What happens after the user clicks "Finish" and "End session" in the self-checkout? Since they're still logged into the Shibboleth IdP, won't they get stuck in an infinite loop? (In reply to David Cook from comment #16) > What happens after the user clicks "Finish" and "End session" in the > self-checkout? Since they're still logged into the Shibboleth IdP, won't > they get stuck in an infinite loop? Well, not an infinite loop. But a loop until they log out of the Shibboleth IdP or that session expires. (In reply to David Cook from comment #16) > (In reply to Alex Buckley from comment #15) > > Hi David, > > > > Thank you for your questions and my apologies for my late reply. > > > > The exact workflow we are wanting to follow with this patchset is: > > > > 1. A patron logs into the OPAC via SSO shibboleth > > > > 2. They visit the self-checkout page > > > > 3. As Koha is configured with AutoSelfCheckAllowed = allowed, and > > AutoSelfCheckId and AutoSelfCheckPass set to a patron with 'circulate' > > permissions that patron is used to automatically authenticate to the > > self-checkout page > > > > 4. Instead of displaying a form asking for the identity (username/password > > or cardnumber) of the patron we want to check out to, our patch skips that > > form by identifying the person logged into the OPAC as the patron to check > > out to > > > > So in short, the only difference in behaviour our patchset should have is > > skipping the form asking for the identity of the patron we want to checkout > > too. > > > > Does this help clarify the intent? > > Thanks, Alex. That does clarify things a bit. > > What happens after the user clicks "Finish" and "End session" in the > self-checkout? Since they're still logged into the Shibboleth IdP, won't > they get stuck in an infinite loop? Thanks David. Ideally, they should be redirected back to the OPAC home page. I see on stock 22.05 that if you hit 'Finish' you're redirected to the form for entering cardnumber or username/password. Checking a test site I have this patchset running on if I hit 'Finish' the self-checkout page re-loads and I am still logged in - see attached screenshot. I had a discussion with Chris and we thought it would be a good idea if I move some of the patchset logic I have in C4/Auth->checkauth() and sco-main.pl into a new subroutine in C4/Auth_with_shibboleth.pm. What are your thoughts on this? Created attachment 138523 [details]
Still logged into self checkout page after selecting Finish
(In reply to Alex Buckley from comment #18) > Ideally, they should be redirected back to the OPAC home page. I see on > stock 22.05 that if you hit 'Finish' you're redirected to the form for > entering cardnumber or username/password. Yeah, out of the box, it redirects back to sco-main.pl, which makes sense for physical self-checkout kiosks. It could be interesting to have a "SelfCheckoutRedirect" system preference that specifies where the user gets redirected to. Or even an additional parameter for sco-main.pl like "mode=online" which causes "Finish" to return to opac-main.pl instead of sco-main.pl. > Checking a test site I have this patchset running on if I hit 'Finish' the > self-checkout page re-loads and I am still logged in - see attached > screenshot. That's what I was expecting as well. I suppose in your scenario you wouldn't want the user to be logged out from the IdP, because they might still have other OPAC work that they want to do. > I had a discussion with Chris and we thought it would be a good idea if I > move some of the patchset logic I have in C4/Auth->checkauth() and > sco-main.pl into a new subroutine in C4/Auth_with_shibboleth.pm. What are > your thoughts on this? I'd need to double-check C4/Auth->checkauth() and C4/Auth_with_shibboleth.pm, but I agree about moving much of the code out of sco-main.pl and putting it into C4/Auth_with_shibboleth.pm for sure. -- I'm waiting on some client requirements for SAML SSO in SCO, and when I get those I should be able to provide more useful feedback/assistance as well. (In reply to David Cook from comment #20) > I'm waiting on some client requirements for SAML SSO in SCO, and when I get > those I should be able to provide more useful feedback/assistance as well. I've heard back and their requirement is to use SAML SSO for SCO when the SCO is a dedicated physical terminal in the library. I'm going to see if they can do LDAP instead as it'll be more straightforward, but here's my thought for a physical terminal SCO: 1. Go to SCO landing page 2. Click button to trigger SSO login 3. Redirect to SSO IdP 4. Login to SSO IdP 5. Redirect back to Koha SCO 6. Create Koha SCO session using the JWT 7. Redirect back to SSO IdP for logout 8. Redirect back to Koha SCO to proceed with JWT It's a multi-hop process, but it could be smooth unless the SSO IdP has a prompt for the logout. I have less experience with SAML than OpenID Connect. With OIDC, you redirect to a logout URL with a post_logout_redirect_uri, and it returns you to Koha without the user really being any the wiser. The alternative would be redirecting to the SSO IdP for logout when clicking "Finish" or during a SCO timeout but... that seems more error prone to me. Someone might step away and not fully logout and then someone else has access to their authenticated session from a dedicated physical terminal... -- Less of an issue of course if they're doing the self-checkout from their own device online. That's why I'm thinking we might need some way of differentiating the two scenarios... (In reply to David Cook from comment #21) > (In reply to David Cook from comment #20) > > I'm waiting on some client requirements for SAML SSO in SCO, and when I get > > those I should be able to provide more useful feedback/assistance as well. > > I've heard back and their requirement is to use SAML SSO for SCO when the > SCO is a dedicated physical terminal in the library. > > I'm going to see if they can do LDAP instead as it'll be more > straightforward, but here's my thought for a physical terminal SCO: > > 1. Go to SCO landing page > 2. Click button to trigger SSO login > 3. Redirect to SSO IdP > 4. Login to SSO IdP > 5. Redirect back to Koha SCO > 6. Create Koha SCO session using the JWT > 7. Redirect back to SSO IdP for logout > 8. Redirect back to Koha SCO to proceed with JWT > > It's a multi-hop process, but it could be smooth unless the SSO IdP has a > prompt for the logout. > > I have less experience with SAML than OpenID Connect. With OIDC, you > redirect to a logout URL with a post_logout_redirect_uri, and it returns you > to Koha without the user really being any the wiser. > > The alternative would be redirecting to the SSO IdP for logout when clicking > "Finish" or during a SCO timeout but... that seems more error prone to me. > Someone might step away and not fully logout and then someone else has > access to their authenticated session from a dedicated physical terminal... > > -- > > Less of an issue of course if they're doing the self-checkout from their own > device online. > > That's why I'm thinking we might need some way of differentiating the two > scenarios... Hey David, Thanks very much for that information. It is interesting to hear a different workflow. Yes, I agree differentiating the two use cases of SSO with SCO is a good idea: Our use case is patrons checking out items on their own devices online, whereas, yours is on a shared dedicated terminal. As you say in comment #20 in our use case we do not want the user to be logged out from the IdP, because they may still have other work to do in the OPAC. We could differentiate the two scenarios using a syspref, and perhaps try upstreaming the two scenarios on two separate bug reports? (In reply to Alex Buckley from comment #22) > We could differentiate the two scenarios using a syspref, and perhaps try > upstreaming the two scenarios on two separate bug reports? Could you elaborate on that? Do you mean a syspref to control the Single Logout (SLO)? I suppose my idea of using a URL parameter to differentiate isn't realistic since people have already bookmarked the SCO for multiple different scenarios... If my client goes the LDAP route, I won't be working on this anyway, so it might not matter. I've been taking a very different approach to a similar feature to this over on bug 30979 (patches not attached yet as I'm still working on it).. In my approach, instead of using the existing SCO pages, I just add a 'Trusted' option that allows OPAC users to checkout to themselves via a new self checkout modal once they're logged in.. This negates the need for a double login (i.e. the SCO login + the user login).. and it should work with all login types (Local, Shibboleth, LDAP etc) Hi David and Martin, Many thanks both for your input. (In reply to David Cook from comment #23) > Could you elaborate on that? > > Do you mean a syspref to control the Single Logout (SLO)? > Yes that's right a syspref to control the Single Logout (SLO). (In reply to Martin Renvoize from comment #24) > I've been taking a very different approach to a similar feature to this over > on bug 30979 (patches not attached yet as I'm still working on it).. > > In my approach, instead of using the existing SCO pages, I just add a > 'Trusted' option that allows OPAC users to checkout to themselves via a new > self checkout modal once they're logged in.. This negates the need for a > double login (i.e. the SCO login + the user login).. and it should work with > all login types (Local, Shibboleth, LDAP etc) That sounds like a good way to handle users checking out to themselves. I'll be interested to have a play with your patches once you're completed and see if they could be a replacement for this patchset. Kind regards, Alex (In reply to Martin Renvoize from comment #24) > I've been taking a very different approach to a similar feature to this over > on bug 30979 (patches not attached yet as I'm still working on it).. > > In my approach, instead of using the existing SCO pages, I just add a > 'Trusted' option that allows OPAC users to checkout to themselves via a new > self checkout modal once they're logged in.. This negates the need for a > double login (i.e. the SCO login + the user login).. and it should work with > all login types (Local, Shibboleth, LDAP etc) I love it. I was thinking it would be good to have separate functionality for that scenario but I wasn't willing to build it [U+1F605]. I'm going to mark this bug report as a duplicate of bug 30979. Martin: As you said in comment #24 it is a fairly similar use case, but a very different approach. I much prefer your approach on bug 30979 . Thanks everyone for your thoughts on this bug report. *** This bug has been marked as a duplicate of bug 30979 *** *** Bug 23989 has been marked as a duplicate of this bug. *** |