[FEATURE] Perpetuate Skip_users behaviour from ldap2 Backend

[ghost]

In my company, I use as auth backend:

• Internal users
• OIDC Users (based on ldap with Dex)
• Ldap User

With this congifuration, I'm able to handle:

• Production connection without tierce party (thanks to internal users)
• Web-User facing with an SSO OIDC
• Human admin actions with direct LDAP credentials

As you understand, I've same LDAP behind opensearch and Dex, so, same users with same permission.

After deep research (code reading), I've found on ldap and ldap2 backend. I ignore totally difference between them except one with the skip_users directive.

As you can see in code :

• Link to Ldap Backend
• Link to Ldap Backend2

thanks to the difference and ldap2, I can manage to use /^(?!uid=).+$/ regexp to exclude user not authenticated from ldap.

What solution would you like?
I wish simply, this behaviour will continue. And maybe injected into ldap backend with a simple configuration like skip_user_only_on_dn with falseas default value (retro-compatible).

What alternatives have you considered?
I've found this open issue which might could related:

• Adding exclusion rules in role mapping when using LDAP #295
• add include_users as an alternative to skip_users for authorization #488
• [BUG] RegExp to exclude all non ldap users from role search (/.*$(?<!DC=contonso,DC=com)/) is not working #1570

Do you have any additional context?

config:
  dynamic:
    authc:
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: true
        transport_enabled: true
        order: 3
        http_authenticator:
          type: basic
          challenge: true
        authentication_backend:
          type: intern
      openid_auth_domain:
        http_enabled: true
        transport_enabled: true
        order: 1
        http_authenticator:
          type: openid
          challenge: false
          config:
            openid_connect_url: https://xxx
            subject_key: name # which in my case correspond of the uid field from ldap
            roles_key: groups
        authentication_backend:
          type: noop
      ldap:
        description: "Authenticate via LDAP or Active Directory"
        http_enabled: true
        transport_enabled: true
        order: 2
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: ldap2
          config:
            enable_ssl: true
            hosts:
            - xxx
            bind_dn: null
            password: null
            userbase: "ou=People,dc=company,dc=org"
            usersearch: "(&(uid={0})(objectClass=person))"
            username_attribute: uid
    authz:
      roles_from_myldap:
        description: "Authorize via LDAP or Active Directory"
        http_enabled: true
        transport_enabled: true
        authorization_backend:
          type: ldap2
          config:
            enable_ssl: true
            enable_start_tls: false
            enable_ssl_client_auth: false
            verify_hostnames: true
            hosts:
             - xxx
            bind_dn: "uid=auth,ou=Auth,dc=company,dc=com"
            password: "xxx"
            skip_users:
              - '/^(?!uid=).+$/'

[cwperks]

[Triage] @BugMaster510945 Thank you for filing an issue. We would gladly accept a PR for this issue.

See related issue of differences in LDAP backends here: #2216

[cwperks]

I think it would make sense to add a new config setting onto the authc entry for the LDAP authentication backend to refer to the respective authorization backend it needs to lookup roles. In the below example, I've added a setting called authorization_backend and the value refers to the name of the respective authorization backend (roles_from_myldap from your example)

i.e.

ldap:
  description: "Authenticate via LDAP or Active Directory"
  http_enabled: true
  transport_enabled: true
  order: 2
  http_authenticator:
    type: basic
    challenge: false
  authentication_backend:
    type: ldap2
    config:
      enable_ssl: true
      hosts:
      - xxx
      bind_dn: null
      password: null
      userbase: "ou=People,dc=company,dc=org"
      usersearch: "(&(uid={0})(objectClass=person))"
      username_attribute: uid
      authorization_backend: roles_from_myldap

Instead of looping through the authorizers in the BackendRegistry after successful authentication, the logic could instead look to see if there is a specific authorization_backend defined in the settings of the authenticator and opt to use that specific authorization backend instead of trying all.