Moodle
  1. Moodle
  2. MDL-29715

tokens are used as authorization instead of authentication only.

    Details

    • Testing Instructions:
      Hide

      1) tokens should not be deleted when removing a user from a web service's authorized list. The token should belong to the user.

      Show
      1) tokens should not be deleted when removing a user from a web service's authorized list. The token should belong to the user.
    • Affected Branches:
      MOODLE_21_STABLE, MOODLE_22_STABLE
    • Rank:
      19227

      Description

      At present web service tokens are displayed as linked with web services in the 'create tokens' page (admin/webservice/tokens.php) and 'security keys' page (/user/managetoken.php)
      This implies that the token is used to not only authenticate the user but to also authorize the user for this web service.

      Imo, Tokens should be used to identify a person ie: authenticate , it is akin to a username/password combination.

      • This way we could also control access based on the type of authentication used if there are more infuture (token or others).
      • using it straight away for authorization can lead to security loop holes when considering future multiple ways of authentication.
      • This could also lead to other scalability problems when many separate web services are required. How many tokens will a user need then?

      There should only be a single token ever needed to be created for each user.

      This token should be able to be created at anytime and reset anytime irregardless of web services linked.

      The token should be reused to link to separate web services, deletion/disabling of these links to web services should not require deletion of a users token! (to resolve MDL-28670 and MDL-28126)

      btw, these links should also be disabled according to other login restrictions (see MDL-28629)

        Issue Links

          Activity

          Hide
          Aparup Banerjee added a comment -

          linking mentioned issues

          Show
          Aparup Banerjee added a comment - linking mentioned issues
          Hide
          Jérôme Mouneyrac added a comment -

          I was confused first that the back end didn't match the UI, and that the back end didn't check that the token were linked to the service. So I thought it was a bug and I set this issue as STABLE backlog. In fact the backend does the ckecking. In conclusion this issue is a dev issue, I set it to DEV backlog. All STABLE backlog linked issues will be unlinked, they need to be resolved. Thanks.

          Show
          Jérôme Mouneyrac added a comment - I was confused first that the back end didn't match the UI, and that the back end didn't check that the token were linked to the service. So I thought it was a bug and I set this issue as STABLE backlog. In fact the backend does the ckecking. In conclusion this issue is a dev issue, I set it to DEV backlog. All STABLE backlog linked issues will be unlinked, they need to be resolved. Thanks.
          Hide
          Aparup Banerjee added a comment -

          we need to separate the access to ws to make it finer.. granular.

          1) token (username/pwd) is used to 'sign in' to the ws. They should be able to 'change password' = change token.
          2) That above is defining sign in to a ws. we need to 'sign in' (more sub-tokens??) to the functions so that we can control functions access separately with more granularity. recent example was ws/pluginfile needing more access information so that not just token to ws permission was checked but also context+function checks..

          Show
          Aparup Banerjee added a comment - we need to separate the access to ws to make it finer.. granular. 1) token (username/pwd) is used to 'sign in' to the ws. They should be able to 'change password' = change token. 2) That above is defining sign in to a ws. we need to 'sign in' (more sub-tokens??) to the functions so that we can control functions access separately with more granularity. recent example was ws/pluginfile needing more access information so that not just token to ws permission was checked but also context+function checks..
          Hide
          Aparup Banerjee added a comment -

          Linking what seems to be related problems being faced (imo)

          Show
          Aparup Banerjee added a comment - Linking what seems to be related problems being faced (imo)
          Hide
          Jérôme Mouneyrac added a comment - - edited

          Note that the download script (webservice/pluginfile.php) checks if the service linked to the token allows download. I doubt such kind of refactor will be done anytime soon.

          Show
          Jérôme Mouneyrac added a comment - - edited Note that the download script (webservice/pluginfile.php) checks if the service linked to the token allows download. I doubt such kind of refactor will be done anytime soon.
          Hide
          Petr Škoda added a comment -

          Yes, tokens are meant to do authorisation and authentication at the same time. This is intentional because there is no other way to restrict the use of web services and their parameters - we must not allow one token to access everything the user can access!

          The basic token restrictions are:

          • user who is impersonated - it is used for setting up of $USER and capability checks, please note that you often give your token to some other system
          • the context where is the token usable - this way you may restrict the validity of token to a specific activity only, this is extremely valuable when giving your tokens to 3rd parties
          • name of web service - this limits the set of functions that are available to token owner, this is again extremely valuable when giving your tokens to 3rd parties, for example you want messaging application to access only messages, not your homeworks or personal files

          Please close this issue as not a bug and if necessary update documentation to reflect the ideas I described above.

          Show
          Petr Škoda added a comment - Yes, tokens are meant to do authorisation and authentication at the same time. This is intentional because there is no other way to restrict the use of web services and their parameters - we must not allow one token to access everything the user can access! The basic token restrictions are: user who is impersonated - it is used for setting up of $USER and capability checks, please note that you often give your token to some other system the context where is the token usable - this way you may restrict the validity of token to a specific activity only, this is extremely valuable when giving your tokens to 3rd parties name of web service - this limits the set of functions that are available to token owner, this is again extremely valuable when giving your tokens to 3rd parties, for example you want messaging application to access only messages, not your homeworks or personal files Please close this issue as not a bug and if necessary update documentation to reflect the ideas I described above.
          Hide
          Aparup Banerjee added a comment -

          Thanks for clarifying that Petr.

          I've tagged this MDL with docs and dev docs so that any possible docs that need updating can be looked at.

          closing this as won't fix since 'there is no other way' was mentioned which seems to hint that there might be a better way. (There's still a slight risk but anyway, no problems out there it seems.) users/admins must simply be made aware.

          Show
          Aparup Banerjee added a comment - Thanks for clarifying that Petr. I've tagged this MDL with docs and dev docs so that any possible docs that need updating can be looked at. closing this as won't fix since 'there is no other way' was mentioned which seems to hint that there might be a better way. (There's still a slight risk but anyway, no problems out there it seems.) users/admins must simply be made aware.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: