This pages describes the relevant WordPress actions and filters which are used during NADI’s authentication workflow

#Non-SSO

As you can see, NADI has two registered hooks for authenticate: Adi\Authentication\LoginService::authenticate and Adi\Authorization\Service::authorize.

• wp_authenticate() (source)
  • apply_filters(‘authenticate’) (show default filters)

    • Adi\Authentication\LoginService::authenticate
      NADI has the highest priority and checks the username and password against the Active Directory. If LoginService::authenticate returns a valid WP_User object, other wp_authenticate_* methods are skipped. Each of those methods checks if one of the further hooks has returned a valid WP_User object and won’t proceed with its own implementation.

    • wp_authenticate_username_password()

      • apply_filters(‘wp_authenticate_user’)
      • wp_check_password()
        • apply_filters(‘check_password’)

    • wp_authenticate_email_password()

      • apply_filters(‘wp_authenticate_user’)
      • wp_check_password()
        • apply_filters(‘check_password’)

    • wp_authenticate_spam_check()

      • apply_filters(‘check_is_user_spammed’)

    • Adi\Authorization\Service::authorize
      The AuthorizatioService itself registers a hook for authenticate with the lowest priority, so we can fake our own authorization workflow. WordPress does not know anything about authorization but only authentication. The registered hook for authenticate itself applies NADI’s own filter authorization.

      • apply_filters(‘authorization’)
        • Adi\Authorization\Service::isUserInAuthorizationGroup
        • Adi\Authorization\Service::isUserEnabled

#SSO

If and when SSO is used, we do not use the normal wp_authenticate workflow as we have to hook into WordPress as early as it can be. The init action is the way to go:

• do_action(‘init’) (source)
  • Adi\Authentication\SingleSignOn\Service::authenticate
    • call AuthorizationService::authorize
    • apply_filters(‘authorization’)