No warning when multiple providers with identical routing identifier used in same outpost

[Ma27]

Describe the bug When having two applications (called A, B) bound to an LDAP outpost and A has a User/Group binding, the LDAP bind against B breaks with "Insufficient access" if the service account for B isn't allowed in A's user/group binding.

To Reproduce

• Create a group "hydra-users"
• Create a group "ldap-search" with two service accounts as members (called "nextcloud-user-sync" & "hydra")
• Create the applications "nextcloud user sync" & "hydra". Both are of type LDAP and use ldap-search as search group
• Create an LDAP outpost with both application providers being part of it.
• Add two user bindings to application Hydra: one allows access for the service user "hydra", the other grants access to the application to group "hydra-users"
• Bind as "nextcloud-user-sync" against the LDAP outpost

You'll get an "Insufficient access" error now whereas binding as "hydra" works fine. The workaround is to grant "nextcloud-user-sync" access to the Hydra application.

Expected behavior

I'm not sure. At first, I thought that this is clearly a bug, but then I realized that this is potentially expected behavior since you don't want to allow binding against an application with user/group restrictions (even if it's just the service account for another application).

OTOH this behavior was pretty unexpected to me, so I'd expect to have a warning at least in the UI. Or maybe even in the logs (i.e. user denied because of user/group bindings from application hydra).

Another option would be to always let the binds of service accounts through.

In other words: this may be an issue, but I'm not sure yet what's the best solution out of it.

Screenshots n/a

Logs n/a

Version and Deployment (please complete the following information):

• authentik version: 2024.2.2
• Deployment: NixOS 23.11 via https://github.com/nix-community/authentik-nix/

Additional context n/a

[BeryJu]

The definitely sounds like a bug, after successfully binding the outpost uses the /core/applications/{slug}/check_access/ API with the session that was just authenticated by the flow and thus it should correctly check access to the correct application. Although one thing that could also cause this behaviour is if both of your LDAP providers have the same base DN, as the outpost will use them to determine which application the request belongs to.

[Ma27]

Although one thing that could also cause this behaviour is if both of your LDAP providers have the same base DN, as the outpost will use them to determine which application the request belongs to.

Sorry, should've mentioned that, they do indeed (all the stuff used the same OpenLDAP server before, so I decided to keep the base DN to make it a little easier).

[BeryJu]

Having multiple LDAP providers with the same Base DN is supported, however they can't be in the same outpost

[Ma27]

So I hope I didn't just miss it in the docs somewhere, but I think it might help to display a warning if that is about to be configured, no?

[BeryJu]

There is a note towards the top of https://docs.goauthentik.io/docs/providers/ldap/, but it should definitely also be shown in the admin UI

[authentik-automation[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Ma27]

I think displaying a warning should be done here since it's very painful to debug if you made the mistake.

[authentik-automation[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Ma27]

https://fvsch.com/stale-bots