• Resolved neenunc

    (@neenunc)


    Hi Team,

    I am using authorizer for LDAP login on our website. We dont want to save the user data(login name, email and hashed password) into the DB as the authentication is done from another thirdparty end.
    How can I disable saving user data(such as email and hashed passwords. keeping user login name is fine) into our DB and depend purely on LDAP?

    • This topic was modified 3 years ago by neenunc.
Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author pkarjala

    (@pkarjala)

    Hi @neenunc,

    The hashed password that is used for the LDAP authentication is not saved to WordPress by Authorizer; instead, a random password is assigned to the user the first time they log in via LDAP and the WordPress user account is created. This is because we are still creating a WordPress user (which is authenticated via LDAP), so we have to set some sort of password in order to maintain security for that user account on WordPress. In case the LDAP connection is removed, the user can still reset their password and log in via WordPress authentication methods.

    Which leads us to the next point; WordPress requires a username, email address, and password for all users. We pull the username and email address from the LDAP record when creating the new user; if the email address does not exist as a record, we instead try to form one based on the username and domain name of the LDAP server.

    You can see the relevant code for the LDAP authentication at https://github.com/uhm-coe/authorizer/blob/8f90f1187b542a50af49bc2a1e9ea15717f26d0c/src/authorizer/class-authentication.php#L893

    We also use the email address from LDAP to match against the local WordPress user account to log the user in after they have authenticated against LDAP. The relevant code for this is at https://github.com/uhm-coe/authorizer/blob/master/src/authorizer/class-authentication.php#L268

    As such, Authorizer currently requires the use of at least the username and email address from LDAP in order to perform a proper match against the WordPress user for permissions and authorization after the LDAP authentication occurs.

    Please let me know if you have additional questions!

    Plugin Author pkarjala

    (@pkarjala)

    There has been no further response to this issue after a week, so we’re going ahead and marking it resolved. Please let us know if you need additional assistance!

    Thread Starter neenunc

    (@neenunc)

    The hashed password that is used for the LDAP authentication is not saved to WordPress by Authorizer; instead, a random password is assigned to the user the first time they log in via LDAP and the WordPress user account is created. This is because we are still creating a WordPress user (which is authenticated via LDAP), so we have to set some sort of password in order to maintain security for that user account on WordPress. In case the LDAP connection is removed, the user can still reset their password and log in via WordPress authentication methods.
    Suppose I logged via LDAP in to my website for the first time, then it will hash my ldap password into the wp_users table, right?
    Even if my account got deactivated/deleted, will I be able to login with the old credentials?

    Plugin Author pkarjala

    (@pkarjala)

    Suppose I logged via LDAP in to my website for the first time, then it will hash my ldap password into the wp_users table, right?

    Incorrect; the LDAP password is ONLY used for the LDAP user authentication to verify that the user logging in has the correct credentials to match against LDAP. Once that authentication is processed as valid by Authorizer, a couple of different things happen:

    1. If the user does not exist in WordPress, a new WordPress user account is created. The email and username from LDAP are used to create this user. A new random password completely unrelated to the LDAP password is generated and stored in the WP_USERS table.
    1. If the user DOES exist in WordPress, then the user is logged in. No change occurs to the WordPress user account.

    In both cases, the LDAP password is only used for authentication against LDAP. It never gets stored in WordPress.

    If your LDAP account gets deleted, the WordPress user will remain. However, the user will be unable to log in with LDAP credentials. They would have to reset their WordPress password and use local account authentication instead. We do this because WordPress users are tied to the content that they create, and deleting a WordPress user account is a process that needs to take into account how you reassign ownership of this content.

    If the WordPress account is deleted, then depending on the settings in Authorizer, a new WordPress user account will be created if the LDAP user attempts to log in again. Authorizer has different settings for whether to just allow all external account authentications to have accounts created, or to put them in an admin queue to be verified by the WordPress admin user before being allowed into WordPress.

    Plugin Author pkarjala

    (@pkarjala)

    There have been no further posts on this topic; marking resolved!

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Not to save user data in wordpress DB.’ is closed to new replies.