Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-79520

Replace custom Clever SSO implementation with OIDC implementation

XMLWordPrintable

    • MOODLE_402_STABLE
    • MOODLE_404_STABLE
    • MDL-79520-main
    • Hide

      Setup

      1. Create a new site, but don't install it yet
      2. Check out weekly/on-demand/beta, as we need to test the upgrade in this test:

        git checkout c6e727732a7f3f106

      3. Install your site now
      4. See MDLQA-16741 and complete the "Prerequisites/Setup" section.
      5. Again, from MDLQA-16741, run through the "Testing" steps. This just confirms we have a working legacy Clever SSO setup.
      6. When you sign in as a teacher/student user above, edit your profile and take note of the idnumber as we'll check this later (under the "Optional" fieldset)

      Testing upgrade

      1. Now, checkout the main branch (or, if you're testing during peer review, apply the patch):

        git checkout main

      2. Via the web, upgrade the site and verify no errors are seen
      3. Go to "Site admin > Server > OAuth 2 services"
      4. Edit the "Clever" issuer
      5. Verify the base URL is set to 'https://clever.com'
      6. Cancel and go back to the issuers list
      7. Now view the endpoints for the issuer
      8. Verify that you see at least the following endpoints (and corresponding values):
      9. Go back to the issuer list
      10. View the user field mappings for the issuer
      11. Verify that you see the following fields mappings:
        • email: email
        • sub: idnumber
        • given_name: firstname
        • family_name: lastname
      12. Log out
      13. Again, from MDLQA-16741, run through the "Testing" steps. This just confirms we have a working upgraded Clever SSO setup now
      14. Again, edit the profile of the user
      15. Verify the idnumber matches the value you noted earlier before the upgrade.

      Testing new integrations

      1. See MDLQA-16741 and complete the "Prerequisites/Setup" section to create another integration with Clever but call this one "CLEVER 2" or something to make it clear it's been created after upgrade.
      2. Edit the "CLEVER 2" issuer you just created
      3. Verify the base URL is set to 'https://clever.com'
      4. Cancel and go back to the issuers list
      5. Now view the endpoints for the issuer
      6. Verify that you see at least the following endpoints (and corresponding values):
      7. Go back to the issuer list
      8. View the user field mappings for the issuer
      9. Verify that you see AT LEAST the following fields mappings (there will be other mappings as this has now run through the openidconnect class and that supports more):
        • email: email
        • sub: idnumber
        • given_name: firstname
        • family_name: lastname
      10. Log out
      11. Again, from MDLQA-16741, run through the "Testing" steps. This just confirms we have a working newly create Clever SSO setup now
      Show
      Setup Create a new site, but don't install it yet Check out weekly/on-demand/beta, as we need to test the upgrade in this test: git checkout c6e727732a7f3f106 Install your site now See MDLQA-16741 and complete the "Prerequisites/Setup" section. Again, from MDLQA-16741 , run through the "Testing" steps. This just confirms we have a working legacy Clever SSO setup. When you sign in as a teacher/student user above, edit your profile and take note of the idnumber as we'll check this later (under the "Optional" fieldset) Testing upgrade Now, checkout the main branch (or, if you're testing during peer review, apply the patch): git checkout main Via the web, upgrade the site and verify no errors are seen Go to "Site admin > Server > OAuth 2 services" Edit the "Clever" issuer Verify the base URL is set to 'https://clever.com' Cancel and go back to the issuers list Now view the endpoints for the issuer Verify that you see at least the following endpoints (and corresponding values): authorization_endpoint: https://clever.com/oauth/authorize token_endpoint: https://clever.com/oauth/tokens userinfo_endpoint: https://api.clever.com/userinfo jwks_uri: https://clever.com/oauth/certs Go back to the issuer list View the user field mappings for the issuer Verify that you see the following fields mappings: email: email sub: idnumber given_name: firstname family_name: lastname Log out Again, from MDLQA-16741 , run through the "Testing" steps. This just confirms we have a working upgraded Clever SSO setup now Again, edit the profile of the user Verify the idnumber matches the value you noted earlier before the upgrade. Testing new integrations See MDLQA-16741 and complete the "Prerequisites/Setup" section to create another integration with Clever but call this one "CLEVER 2" or something to make it clear it's been created after upgrade. Edit the "CLEVER 2" issuer you just created Verify the base URL is set to 'https://clever.com' Cancel and go back to the issuers list Now view the endpoints for the issuer Verify that you see at least the following endpoints (and corresponding values): authorization_endpoint: https://clever.com/oauth/authorize token_endpoint: https://clever.com/oauth/tokens userinfo_endpoint: https://api.clever.com/userinfo jwks_uri: https://clever.com/oauth/certs (we don't expect to see this, because the openidconnect class isn't very smart and won't discover it - but that's ok because we don't use it - but we should) Go back to the issuer list View the user field mappings for the issuer Verify that you see AT LEAST the following fields mappings (there will be other mappings as this has now run through the openidconnect class and that supports more): email: email sub: idnumber given_name: firstname family_name: lastname Log out Again, from MDLQA-16741 , run through the "Testing" steps. This just confirms we have a working newly create Clever SSO setup now
    • 2
    • Team Hedgehog 2023 Review 4, Team Hedgehog 2024 Sprint 1.1

      Currently, the Clever service template exhibits the following:

      1. It isn't using Clever's OIDC 'userinfo' endpoint, which means there is a custom 'client' subclass calling non-standard endpoints to get user information.
      2. The above also means we have a custom user field mapping, mapping these non-standard fields into our internal fields.
      3. Has hard-coded endpoints (no OIDC discovery)

      Sidenote: Whilst we definitely should be reading user information from the (verified) id_token, that's another story and is a wider problem across Moodle's OIDC implementation (and not a problem that should be tackled here).

      For Clever, we should at the very least:

      1. Use discovery to read+store Clever's OIDC endpoints (including the userinfo endpoint). I've spoken to Clever about their broken discovery endpoint and this has now been fixed, so we can now use this: https://clever.com/.well-known/openid-configuration
      2. Use the userinfo endpoint to get the user data during auth, instead of the 2-call method we were currently using.

            jaked Jake Dallimore
            jaked Jake Dallimore
            Meirza Meirza
            Jun Pataleta Jun Pataleta
            Ron Carl Alfon Yu Ron Carl Alfon Yu
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved:

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 1 day, 8 minutes
                1d 8m

                  Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.