Can't connect via ldap-proxy plugin

[gitalexch]

Top-level intent

Can't Connect via ldap-proxy with "privacyIDEA-LDAP-Proxy" User-Agent value

Steps to reproduce

1. Connecting with "privacyIDEA-LDAP-Proxy" User-Agent -- get 400 error
2. Connecting with "FreeRADIUS" User-Agent -- All OK.

Expected outcome

The UserAgent should be possible to configure

Actual outcome

What did actually happen?

Configuration

• privacyIDEA version: 3.7+
• Installation method: from PyPI, ...)
• Python version: 3.10+
• Operating system: AlmaLinux 9
• Webserver: nginx
• Token database: PostgreSQL

Log file

Set PI_LOGLEVEL = logging.DEBUG in pi.cfg and take a look at the privacyidea.log!
If appropriate, attach the log file or paste relevant portions.
ldapsearch -D 'CN=otptest,OU=Test,OU=_Users,DC=my,DC=domain' -W -H ldaps://127.0.0.1:636 -b 'DC=my,DC=domain'
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
additional info: Failed to authenticate. Wrong HTTP response (400)

It seems, that User-Agent FreeRADIUS is somewhere hardcoded and it could connect without authorisation, I was tried to find, but failed, so I think that it should be configurable and maybe additionally protected by unexpired tocken

[github-actions]

Thank you for filing an issue and sharing your observations or ideas. Please be sure to provide as much information as possible to help us to work on this issue.

[gitalexch]

Can be closed(or changed to future request) I have found in log, that "No subscription for your client." and finale answer at community, but anyway I suggest to add token to applications(i.e. to pi-ldapproxy and FreeRADIUS ) to protect from unauthorised requests and add more detailed return code(something like "Error 400 No subscription for your client.").

[plettich]

We already use the user-agent value to determine the plugin (and it's corresponding subscription).
We'll have to discuss if we want to augment the 400 error-message.

[gitalexch]

Yes, but the plugin could be standalone and communicate via public network not only localhost interface, it seems using token for protection could be good Idea, maybe add token to subscription to additional verification?

[plettich]

Yes, but the plugin could be standalone and communicate via public network not only localhost interface, it seems using token for protection could be good Idea, maybe add token to subscription to additional verification?

Hi @gitalexch i am not sure if i understand You correctly. Do You mean adding some kind of secret token to the user-agent string? Like User-Agent: privacyIDEA-LDAP-Proxy/10/<secret token>?
We can already require a valid API-key:
https://privacyidea.readthedocs.io/en/v3.9.2/policies/authorization.html#api-key-required

[gitalexch]

Hi, Yes, I mean something like API-key, maybe not in User-Agent attribute, but separate in Authorization or PI-Authorization attribute and built into subscription with subscription expiration date and so on...

And, I think it would be correct if you change label to Feature request....