Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-15021

Fallback to non-proxied Authz update when Proxied authorization update fails

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 6.0.0, 6.0.0.1, 6.0.0.2, 6.0.0.3, 6.0.0.4, 6.0.0.5, 6.5.0, 6.0.0.6, 6.5.0.1, 6.5.1
    • Fix Version/s: 6.0.1, 7.0.0, 6.5.3
    • Component/s: idrepo, self-service
    • Labels:
    • Environment:
    • Target Version/s:
    • Rank:
      1|hzydb3:
    • Sprint:
      AM Sustaining Sprint 64
    • Story Points:
      3
    • Needs backport:
      No

      Description

      Problem

      On a DataStore with proxy-authz enabled and the binding user the the directory have proxy-auth privilege to update all users, the datastore have users that have password policies (and also account locked) password updates on these are the users will fail.

      Hence even if the admin is logged into the system and the datastore which is proxied-authz will not let the admin to reset the password. This RFE is to provide a fallback to use non-proxied updated as a fallback.

      The proxied-authz feature was introduce for the password-reset case (for LDAP password policy) to avoid double password reset. However this cause update when the account is locked/expired/password expired. So we need a way to have admin reset password w/o creating say another realm/subrealm without proxied-authz.

      Testcase

      • Follow the setup as in OPENAM-14881
      • You will see if the user password is locked, expired or account locked,if
        proxy-authz is enabled, self-service password forgot reset and admin changing
        on the admin-console for the user passsword will fail.

      Expected RFE

      • Permit console admin to perform password change on proxied-authz
      • Self-service user can still perform proxied-authz

      Proposal

      • Provide a fallback to use non-proxied authz (ie as if it is not enabled) when proxied authz fails. This will address the admin reset usecase.

      As for the self-service this is as if the case without proxied-authz feature exists when it fails. This is not a problem last time because that feature was introduce for the password-reset case (for LDAP password policy) to avoid double password reset. However this cause update when the account is locked/expired/password expired.

      Since it is possible that developer can use AMIdentity.setAttribute/store to change attributes (with AdminToken) [as server side customized), a fallback to non-proxied seems will not cause much security impact and work.

      So the admin console DJLDAPv3Repo may look like this with the fallback option

       

      Test procedure/Expected list

      • Setup an users with
        a) password-reset enabled
        b) password-reset with password expired
        c) account-locked.
        d) Normal user
      For Admin user (console test),

      a) resetting password on locked account/password expired

      • proxied-authz enabled ==> fails (Change not authorized / ldapError=123)
      • non-proxied ==> ok, but when user logging (LDAP module), password reset on login
      • proxied-authz+fallback ==> same as non-proxied case

      b) resetting password on normal user

      • proxied-authz enabled ==> no password reset
      • proxied-authz+fallback ==> no password reset
      For self-service forgotten password

      a) on locked account/password expired

      • proxied-authz enabled ==> fails (Change not authorized / ldapError=123)
      • non-proxied ==> no error, but when user logging (LDAP module), password reset on login
      • proxied-authz+fallback ==> same as above

      b) resetting password on normal user

      • proxied-authz enabled ==> no password reset
      • non-proxied ==> password reset
      • proxied-authz+fallback ==> no password reset (since fallback not taken)

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              chee-weng.chea C-Weng C
              Reporter:
              chee-weng.chea C-Weng C
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: