Uploaded image for project: 'Syncope'
  1. Syncope
  2. SYNCOPE-1388

mustChangePassword flag does not prevent user from invoking actions

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.8, 2.1.1
    • Fix Version/s: 2.0.11, 2.1.2, 3.0.0
    • Component/s: core
    • Labels:
      None

      Description

      If a user has mustChangePassword set to true, the user can normally authenticate himself (which is expected), get his user information and even trigger a self-update on his user object. The later two should not be allowed.

      Before the user can do anything except acquire an accesstoken, he should call /users/self/mustChangePassword API which will change the password and sets the mustChangePassword set to false

      Intended Use-Case

      Use the flag in a password policy, enforcing the user to change the password every e.g. 90 days.

      To reproduce the issue using the REST-API
      Given the admin has set the "mustChangePassword" flag to "true" for user "rossini"

      When the user "rossini" acquire an accesstoken, then the access token is returned. (I haven't tested the behavior with basic Auth.) - correct behaviour!

      When the user "rossini" queries GET /users/self, then the user object is returned and the header "x-syncope-entitlements: {"MUST_CHANGE_PASSWORD":[]}" is set.
      Expected: Return error 403 with additional information that password must be reset.

      When the user "rossini" uses PATCH /users/self and sets the "mustChangePassword" flag to "false", then the user object is updated (status 200).
      Expected: Return error 403 with additional information that password must be reset.

        Attachments

          Activity

            People

            • Assignee:
              ilgrosso Francesco Chicchiriccò
              Reporter:
              lfunk Lukas Funk
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: