Iam 998

[nsklikas]

IAM-998

Allow glauth to act as an ldap broker. The main problem with the current approach is that the ldap requests are proxied to the remote ldap server as they are, which means that we have to provide the same bind_dn and password to all the applications that relate with the proxy. Not much we can do on that end (other than push upstream).

Question:

• Should we allow for multiple backends?
• Split integration tests in multiple files?

TODO:

• In another PR we will refactor the integration tests to perform some basic ldap search

[shipperizer]

should we allow multiple backends?

my short answer is yes, or better we should allow it knowing that glauth has a callback behaviour (or that s what I gathered from reading the docs last time around)

long answer is "it depends" as I recall there was an interest in having glauth to perform an aggregation between backends, which I'm not sure it's possible but I might be wrong

[nsklikas]

my short answer is yes, or better we should allow it knowing that glauth has a callback behaviour (or that s what I gathered from reading the docs last time around)

long answer is "it depends" as I recall there was an interest in having glauth to perform an aggregation between backends, which I'm not sure it's possible but I might be wrong

The behavior I have witnessed (without testing it too much) is that the 1st backend is used for finding the user, ie if the user is not in there then the call fails, and the 2nd backend is used to enhance the user's attributes if the user is not found in there then only the attributes found in the 1st backend (the call does not fail).

The problem with this is that we can't insert users in the external ldap service, which means we won't be able to automatically create accounts for the charms that are related using the ldap integration.
Also if we allow multiple ldap backends it will be hard to reason about which one we should use as "primary".