Active Directory setup questions

[bitmapbulgaria]

Although Hajk supports Active Directory integration, there is not much explanations and description for such setup.
I hope some one can explain the conception and the procedure in more detailed manner.
Few questions and considerations:

1. Should Hajk server (in my case, on Ubuntu machine) be part of the Active Directory to work?
2. Is the proxy part for new-backend& new-admin missing in the source code? There is a folder /proxy/httpproxy, but it seems not to be NodeJS code? Maybe this is some old construction about the windows setup and the classic backend?
3. If so- should the AD_TRUSTED_PROXY_IPS be IP of that missing part(the proxy service), or there should have the AD Server IP? I mentioned, that in the
   config_example.json there is a "url_proxy": "https://YOUR_DOMAIN.COM/util/proxy/geturl/" for the different endpoints, but wondering is
   this the missing proxy code, or it is implemented in the "new" NodeJS variants?

My goal is a setup, where the Internet users (so called- visitors) to access Hajk, but to see different layers and tools, internal authenticated AD users to have access to different set of layers/tools, depending their rights, defined in Admin panel and no rights to access Admin Panel, and the Admins to have full access to all system. (the Admin group is also AD group- for example - as is in the .env - GIS_ADMIN)

P.S. I have succeed to get the ldap://myADserver:389 to work
([2023-07-29T18:25:28.210] [INFO] service.auth - Connection to ldap://10.0.0.101:389 succeeded.),
but still unable to get it to work, the response for getting layers list, for example:
for the request: https://myserver.com/backend/api/v1/config/layers, I get response:
"[getUserFromRequestHeader] AD authentication does not allow requests from ::ffff:127.0.0.1. Aborting."
Maybe I need AD Server to be configured to accept request from HAJK, as well?
Please, someone give a hint. I'm stuck on this...
@jacobwod can you help me on this one?

[Hallbergs]

You're absolutely right that the AD integration lacks proper documentation, and i'm not surprised that you're getting stuck!

First, it's important to understand how the AD integration of the Node backend is supposed to work:

• The backend connects to AD service via LDAP(S) (you have connected successfully, nice!)
• Since we don't have any authentication implemented in the NodeJS backend, the backend expects requests with a header key containing the user making the request (the header can be set in .env - AD_TRUSTED_HEADER, if not set it defaults to X-Control-Header).
• The point above means that you will need a proxy that authenticates users and adds their username to the header that you've chosen (or X-Control-Header).
• The backend will then check (via the LDAP connection) which AD groups the supplied user is part of.
• Since we rely on a proxy handling the authentication, we use the AD_TRUSTED_PROXY_IPS setting to make sure we only allow traffic from the authentication proxy. I would suggest you leave AD_TRUSTED_PROXY_IPS blank and make sure you get everything working before restricting the traffic.

The reason to why we use an authentication proxy is that Hajk has mostly been deployed on internal networks where the authentication proxy already exists. We're planning (not sure when, but the sooner the better) to expand the AD integration so that Hajk can handle the authentication as well, simplifying the deployment.

Me and @jacobwod played with an authentication proxy that authenticates users against Azure AD (or local db) a while a go: https://github.com/hajkmap/authentication-proxy (see the solution more as an example than as a real solution - it is not tested at all ;) )

[bitmapbulgaria]

Thanks a lot!
My solution (for dummies):
NGINX proxying the requests, based on the user real IP: if the IP is outside AD network (IP range), set X-username to "guest". A request from the trusted AD network (for example: 10.0.xxx.xxx) is getting the corresponding AD username via map directive from .map file (setup is implemented in nginx.conf), where the user has "one to one" relation to the IP (the working place).
Not ideal, but it works, for testing purposes.
P.S. I'll try to develop simple auth module, based on NGINX auth directive, will see if it is going to work...

[jacobwod]

Glad to hear you've made some steps in the right direction, @bitmapbulgaria.

I agree with all the above. Keep us updated if you manage to find a better solution than this NGINX based AD flow with X-Control-Header. Thanks!