graylog_ldap_settings api call changed in version +4.x

[witjoh]

Debug: Prefetching graylog_api resources for graylog_ldap_settings
Debug: GET request for https://localhost.:9000/api/system/ldap/settings with params {}
Error: Got error response {"type":"ApiError","message":"HTTP 404 Not Found"}
Error: Could not prefetch graylog_ldap_settings provider 'graylog_api': 

Looking into it preparing PR to solve this.

This is now done using

https://localhost:9000/api/system/authentication/services/backends
https://localhost:9000/api/system/authentication/services/configuration

api calls

[philomory]

We don't use Graylog 4.x ourselves (in part because of the auth system changes) so I'm not easily able to test against it; it might be necessary to make a second type/provider pair for the new auth system, since I'd want to preserve 3.x compatibility for the existing type. Maybe a graylog_auth_backend type?

[witjoh]

think that will be indeed the way to go. especially when 3.x needs to be preserved. Is support for the enterprise features also needed ? In 4.x, the group mapping is only available in the enterprise version.

And there are 4 types of backends (LDAP, Acitve-directory, okta and OIDC) Laast two are enterprise only.

[philomory]

If you're willing to contribute a PR to add the graylog_auth_backend type, you can include support for whichever backends and features you're interested in implementing. If that does not include the Graylog Enterprise features, that's fine, they can always be added later.

I can see a couple of ways to go in terms of implementation:

1. You could add separate graylog_auth_backend_ldap, graylog_auth_backend_active_directory, etc., types
2. You could add a single graylog_auth_backend type which takes a few universal parameters, a paramenter (or perhaps the namevar) to specify which backend in being configured, and then an options parameter for backend-specific configuration. You could then implement wrappers like graylog_api::ldap_auth_backend, graylog_api::active_directory_auth_backend, etc., the way the Input types are handled.

Which method is more appropriate probably depends on what the API looks like on Graylog's side.

[witjoh]

see PR #9