Seamless LDAP configuration

[rhafer]

Description

Describe the bug

Several service in oCIS provide support for LDAP to provide various features. All of them usually access the same LDAP Server (usually also using the same credential to authenticate), but they're all configured in slightly different, sometime cumbersome ways. We should straighten this out and provide a more unified configuration. (And we should do so before GA, as a config migration will likely be complex)

• reva services: authprovider, userprovider, groupprovider These services are all configured in a similar way. The need

  • connection information hostname, port
  • tls settings: insecure, cacert
  • authentication setting for the service user: bind_username, bind_password
  • attribute mappings defining which LDAP AttributeType is used for which attribute of the CS3 API resource
  • a search base (i.e. the starting node in the LDAP tree for all searches)
  • a set of LDAP filters using template vars to define the filters to use for each type of query the service has to perform. E.g. the userprovider needs a userfilter defining the query to lookup a single user by its id. The default config in oCIS is using this value: "(&(objectclass=posixAccount)(|(ownclouduuid={{.OpaqueId}})(cn={{.OpaqueId}})))". Defining the correct filter for this an be quite cumbersome and errorprone. In this example even more as it makes use of go-templating and requires at least basic knowledge about the internal representation of the CS3 UserId Object.
  • Sidenote: with the currently available config options some of the more usual LDAP setups cannot be supported. (E.g. There is no way to configure the groupprovider to work with Active Directory (or any other LDAP server storing groupmember ships as full user DNs) (IIRC I opened an issue in Reva for this a while ago)

• lico idp is configured using:

  • a connection URI
  • authentication setting for the service user
  • attribute mappings defining which LDAP AttributeType is used for which claim
  • A possibility to set the syntax of the UUID attribute to allow binary Attributes (like Active Directory GUIDs) being used as the UUID
  • a search base (i.e. the starting node in the LDAP tree for all searches)
  • a search scope (onelevel vs subtree)
  • a basic LDAP filter to define basic search criteria for a user (usually this is just (objectClass=inetOrPerson))

• graph users/groups API is pretty similar to configure to lico

  • a connection URI
  • authentication setting for the service user
  • attribute mappings defining which LDAP AttributeType is used for which GraphAPI
  • a search base (i.e. the starting node in the LDAP tree for all searches)
  • a search scope (onelevel vs subtree)
  • a basic LDAP filter to define basic search criteria for a user (usually this is just (objectClass=inetOrPerson))

In general all of the above service run similar queries

• Searching a single user/group by id
• Searching users or groups by specific attributes (usually name, login, mail)
• Listing the group memberships of a specific user
• Listing all members of a specifc group
• Authenticating as a specific user (which usually boils down to a search by login + the authentication request)

It should be possible to come up with a more streamlined configuration. Basically the information we need to usefully configure all of the above services should be limited to:

• a connection URI
• TLS Settings
• Bind configuration for the service user
• a search base and scope for user objects
• a basic filter to use for user searches (no templating)
• a search base and scope for group objects
• a basic filter to use for group searches (no templating)
• a setting to define which type of LDAP groups the server provides
  • RFC2307 (group members as usernames in the memberUID attribute
  • RFC2307bis (group members as full DNs in the member attribute
  • AD (similar to RFC2307bis but with user objects maintaining memberOf reference
• attribute mappings (here each service has slightly different requirements)

IMO this would also be somewhat better aligned with how many other projects handle LDAP integration (nss_ldap, sssd). We might also want to take a look into how openstack-keystone does this nowadays.

User Stories

• As an Admin I want to have consistent configuration schemes across all my services to make it less error prone

Value

Understandable and consistent configuration reduces support requests and empowers wider adoption.

Acceptance Criteria

• It is possible to use ocis with Microsoft AD
• LDAP configuration attributes are shared across graph, IDP and reva
• Basic documentation is available

Definition of ready

[ ] everybody needs to understand the value written in the user story
[ ] acceptance criteria has to be defined
[ ] all dependencies of the user story need to be identified
[ ] feature should be seen from an end user perspective
[ ] user story has to be estimated
[ ] story points need to be less then 20

Definition of done

• Functional requirements
  [ ] functionality described in the user story works
  [ ] acceptance criteria are fulfilled
• Quality
  [ ] codre review happened
  [ ] CI is green
  [ ] critical code received unit tests by the developer
  [ ] automated tests passed (if automated tests are not available, this test needs to be created and passed
• Non-functional requirements
  [ ] no sonar cloud issues

[rhafer]

@butonic @micbar Sorry for producing that amount text 😄 , but it helped me quite a bit to write it down. You might think differently about this by IMO we should tackle this soon.