When applying groups membership the LAVA backend was directly applying
what was present in the claim.

However users may be members of manually created groups that are not
supposed to be managed by the mediator, and those memberships should be
preserved.

This is specially useful when transitioning from manually set up groups
to automatic synchronization with the mediator, to ensure that
permissions are retained while the managed groups get set up.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Make the LAVA backend respect the `included_groups` configuration option
and only apply the subset of the groups in the claim that match the
specified pattern.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Edmund Smith authored 2 years ago and Emanuele Aina committed 1 year ago

There are matching downstream changes to LAVA in order to support
this, and it does not seem likely at this point that LAVA upstream
will use usernames to communicate about individual users.

Signed-off-by: Ed Smith <ed.smith@collabora.com>

Andrej Shadura authored 2 years ago and Emanuele Aina committed 1 year ago

Using %w instead of %v makes Errorf store the original error, allowing
the caller to extract and use it later. While there isn’t any immediate
benefit from it, it may be useful in future.

See:
 * https://go.dev/doc/go1.13#error_wrapping
 * https://github.com/golang/go/wiki/ErrorValueFAQ
 * https://go.googlesource.com/proposal/+/master/design/29934-error-values.md



Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>

This adds support for two new low-level LAVA XMLRPC calls:

- system.get_all_users to find all the users present on a LAVA
  instance by email

- system.set_user_active to lock or unlock a user account on a LAVA
  server.

Signed-off-by: Ed Smith <ed.smith@collabora.com>
Co-authored-by: Andrej Shadura <andrew.shadura@collabora.co.uk>

Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>

This is a typo fix that was just overlooked. The URL used in
newLavaClient was hardcoded to be the one for the docker image in the
compose test, rather than using the configured URL.

Note that the URL the lava backend is receiving is the callback URL,
not the root LAVA url. There's no obvious nice way to do this, one
option would be to add another config option with the LAVA root URL,
but instead I've pruned off the (fixed) callback portion.

A lot of these files hadn't yet been run through it.

https://phabricator.apertis.org/T8937



Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>

Edmund Smith authored 2 years ago and Andrej Shadura committed 2 years ago

This is considerably simpler than it might be, because LAVA exports
the API we want - set all the groups to which a user belongs.

The main complication here is that LAVA uses basic authentication,
which means we need an XMLRPC library which supports setting this
header. The majority of go XMLRPC libraries I looked at did not seem
to support this.

Group creation got dropped, so get rid of some leftovers.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Sjoerd Simons authored 2 years ago and Sjoerd Simons committed 2 years ago

As groups have to be configured by hand anyway (to give them relevant
permissions etc) auto-creating groups isn't actually that helpful and
may cause unintended groups to be created. So revert to only adding
users to (existing) groups rather then creating them on demand

Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>

If we, for example, only synchronise groups matching group_*, but a user
was locally added to a group local_group, we don’t want to undo this.
For this reason, filter the existing groups the users are members of,
and only act on the group we care about.

Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>

Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>

Signed-off-by: Paweł Wieczorek <pawel.wieczorek@collabora.com>