Strip comma when baseDN is empty and add option to remove Authorization header before passing to backend

[alexanderharm]

It would be great if the plugin does strip the , from the LDAP-bind if the baseDN is set to "". This would greatly improve compatibility with Active Directory so one could do:

attribute: userPrincipalName (sAMAccountName)
baseDN: ""

Right now this ends results in userPrincipalName=john.doe@example.com, which fails to authenticate.

A nice touch would be the option to remove the Authorization header before passing to the backend, similar to the basicAuth middleware.

Thanks a lot for your consideration.

[wiltonsr]

Hello, @alexanderharm Thanks for your contribution

A nice touch would be the option to remove the Authorization header before passing to the backend, similar to the basicAuth middleware.

This project is an in-progress effort to create an open-source middleware in a similar way to Traefik Enterprise.

The option you are asking for already exists. It's called forwardAuthorization. And here you could check that by default we don't pass the Authorization header to backend.

It would be great if the plugin does strip the , from the LDAP-bind if the baseDN is set to "".

Done in #55. You can check the change in v0.1.5.

[alexanderharm]

Hmm, I did not define the variable which should set it to false, no? However, it still did forward it.

I will test tonight setting it explicitly to false and report back.

[wiltonsr]

You can check it's value in DEBUG mode logs:

traefik  | DEBUG: ldapAuth: 2023/11/23 12:50:35 restricted.go:51: ForwardAuthorization => 'false'

You could also check running the examples.

docker-compose -f examples/conf-from-labels.yml up
curl --user tesla:password -H "Host: whoami.localhost" http://0.0.0.0

You must get something like that:

Hostname: 84639eefcd59
IP: 127.0.0.1
IP: 172.18.0.3
RemoteAddr: 172.18.0.2:52954
GET / HTTP/1.1
Host: whoami.localhost
User-Agent: curl/8.4.0
Accept: */*
Accept-Encoding: gzip
Username: tesla
X-Forwarded-For: 172.18.0.1
X-Forwarded-Host: whoami.localhost
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Server: 3b8d407d5056
X-Real-Ip: 172.18.0.1

And adding the forwardAuthorization option in examples/conf-from-labels.yml and running the above commands again, you must get:

- traefik.http.middlewares.ldap_auth.plugin.ldapAuth.forwardAuthorization=true

Hostname: ac9b92731103
IP: 127.0.0.1
IP: 172.18.0.2
RemoteAddr: 172.18.0.3:41550
GET / HTTP/1.1
Host: whoami.localhost
User-Agent: curl/8.4.0
Accept: */*
Accept-Encoding: gzip
Authorization: Basic dGVzbGE6cGFzc3dvcmQ=
Username: tesla
X-Forwarded-For: 172.18.0.1
X-Forwarded-Host: whoami.localhost
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Server: 3b8d407d5056
X-Real-Ip: 172.18.0.1

Note the Authorization header difference.

I will test tonight setting it explicitly to false and report back.

LMK if have some problem.

[alexanderharm]

I have DEBUG: ldapAuth: 2023/11/23 14:07:04 restricted.go:51: ForwardAuthorization => 'false'

But I can still the the auth header using Wireshark on the backend. I don't want to waste your time. I will have a closer look tonight.

[wiltonsr]

I have DEBUG: ldapAuth: 2023/11/23 14:07:04 restricted.go:51: ForwardAuthorization => 'false'

But I can still the the auth header using Wireshark on the backend.

Weird. Here you can see where we delete the header before passing the request to traefik. https://github.com/wiltonsr/ldapAuth/blob/66002e5b92136ff3ee2e3a391f38c3893ccb651d/ldapauth.go#L228-L236