I wonder why you see those as solutions. They all seem to add unnessary work for everyone.
Because the users are already assigned to system permission groups, and all that is missing is to define galene group permissions based on the system groups.
Regardless of the underlying representation, there will always be some dedicated tool (command) to check the authorization, I don’t know why you want to implement and maintain these things with galene.
For example, even though LDAP is a complicated beast, for yunohost this specific command seems to do all the magic to get the list of authorized groups: (as set up by devs/package maintainers)
# bind with user's credentials (-x -W -D) and
# refine a base search (-b) to memberOf lines
ldapsearch -x -W -D "uid=${user_id},ou=users,dc=yunohost,dc=org" \
-b "uid=${user_id},ou=users,dc=yunohost,dc=org" \
memberOf \
| grep ^memberOf \
| sed 's/^memberOf: cn=//; s/,ou=groups,dc=yunohost,dc=org$//'
The problem in galene is that, as far as I understand, there is no way in galene group.json config files to assign externaly authorized users, and groups of users, to permissions for the specific galene group.
I don’t think galene group permissions can be generalized to application wide permissions, as it seems galene-ldap currently attempted. Permissions are group-specifc.
And think something like a generic galene-auth (possibly replacing galene-ldap and maybe others) that calls configurable external command lines may safe you work, while supporting integration in much more places.