add feature flag for external user management

[wkloucek]

fixes #5
depends on owncloud/ocis#4346

[PixelJonas]

If I see it correctly this "assumes" a specific configuration at the OIDC provider (e.g. there needs to be a client called web and it needs to be public).

When using this together with a keycloak instance (using https://sso.mydomain.com/auth/realms/myrealm and creating a client called web ) I get in a redirect loop with the following error being produced in the auth-machine

auth-machine-5f86bcbb48-r92b7 auth-machine {"level":"debug","service":"auth-machine","pkg":"rgrpc","traceid":"00000000000000000000000000000000","client_id":"username:[email protected]","time":"2022-08-01T10:11:55.76955884Z","message":"unknown client id"}

any idea how I could debug this?

[wkloucek]

If I see it correctly this "assumes" a specific configuration at the OIDC provider (e.g. there needs to be a client called web and it needs to be public).

Right, same applies also for the other clients (iOS / Android / Desktop). You can have import them from these files https://github.com/owncloud/ocis/tree/master/deployments/examples/ocis_keycloak/config/keycloak/clients. For the iOS / Android / Desktop clients, you could also use Dynamic Client Registration instead.

any idea how I could debug this?

I didn't run this PR on my own so far. But I'll do this week. I think there are still some config options missing.

[PixelJonas]

Ah ok, please reach out if can support testing this PR.

[rhafer]

Looks good to me. Needs to wait for ocis beta 6 being released though

[wkloucek]

Needs beta.6 first for owncloud/ocis#4346

[PixelJonas]

Is this at a point where I could test it with Keycloak? If I read owncloud/ocis#4346 this is only for client support on iOS/Android, right? Webbrowser should work?

[wkloucek]

Is this at a point where I could test it with Keycloak? If I read owncloud/ocis#4346 this is only for client support on iOS/Android, right? Webbrowser should work?

I just merged this PR and bumped the oCIS version in #74. So you can just use the chart from master.

Please note that you also need an LDAP server for this setup. Do you plan to use Redhat IDM / SSO for the testing?

Right, Android / iOS / Desktop clients need the wellknown information of the IDP on the oCIS domain, too. Web has a different discovery.

[PixelJonas]

I wanted to test with upstream Keycloak but yeah. What do I need the LDAP server for?

[wkloucek]

I wanted to test with upstream Keycloak but yeah. What do I need the LDAP server for?

We are using OIDC for authentication but for querying users (and groups) we always use LDAP (eg. for sharing a file with another person). Even in the single binary case (ocis server) we start a builtin LDAP server.

For the oCIS Helm Chart we decided to not run the builtin LDAP as an option because it is not designed to scale beyond ~200 user and it only supports a single instance (no HA).

One more feature, the Helm Chart does not support yet, is autoprovisioning the user when the user is only in the OIDC provider but not in the LDAP server. oCIS will then store the user to the LDAP on the first login.

This is the relevant config section for the OIDC and LDAP settings:

ocis-charts/charts/ocis/values.yaml

Lines 86 to 163 in f058a75

	# External user management
	externalUserManagement:
	# -- Enables external user management (and disables internal user management).
	# Needs an external OpenID Connect Identity Provider and an external LDAP server.
	enabled: false
	# OpenID Connect Identity provider related settings.
	oidc:
	# -- Issuer URI of the OpenID Connect Identity Provider.
	# If the IDP doesn't have valid / trusted SSL certificates, certificate validation can be disabled with the `insecure.oidcIdpInsecure` option.
	issuerURI: https://idp.owncloud.test/realms/ocis
	# -- Claim to take an unique user identifier from. It will be used to look up the user on the LDAP server.
	userIDClaim: ocis.user.uuid
	# -- Attribute mapping of for the userIDClaim.
	# Set to `userid` if the claim specified in `...oidc.userIDClaim` holds the value of the ldap user attribute specified in `...ldap.user.schema.id`.
	# Set to `mail` if the claim specified in `...oidc.userIDClaim` holds the value of the ldap user attribute specified in `...ldap.user.schema.mail`.
	# Set to `username` if the claim specified in `...oidc.userIDClaim` holds the value of the ldap user attribute specified in `...ldap.user.schema.id`.
	userIDClaimAttributeMapping: userid
	# LDAP related settings.
	ldap:
	# -- URI to connect to the LDAP secure server.
	uri: ldaps://ldaps.owncloud.test
	# -- Set only to false, if the certificate of your LDAP secure service is not trusted.
	# If set to false, you need to put the CA cert of the LDAP secure server into the secret referenced by "ldapCaRef"
	certTrusted: true
	# -- Disables SSL certificate checking for connections to the LDAP server.
	# -- For self signed certificates, consider to put the CA cert of the LDAP secure server into the secret referenced by "ldapCaRef"
	# Not recommended for production installations.
	insecure: false
	# -- DN of the user to use to bind to the LDAP server.
	# The password for the user needs to be set in the secret referenced by `secretRefs.ldapSecretRef` as `reva-ldap-bind-password`.
	# The user needs to have permission to list users and groups.
	bindDN: uid=ocis,ou=system-users,dc=owncloud,dc=test
	user:
	schema:
	# -- LDAP Attribute to use as the unique id for users. This should be a stable globally unique id like a UUID.
	id: ownclouduuid
	# -- Set this to true if the defined `id` attribute for users is of the `OCTETSTRING` syntax. This is e.g. required when using the `objectGUID` attribute of Active Directory for the user ID`s.
	idIsOctetString: false
	# -- LDAP Attribute to use for the email address of users.
	mail: mail
	# -- LDAP Attribute to use for the displayname of users.
	displayName: displayname
	# -- LDAP Attribute to use for username of users.
	userName: uid
	# -- Search base DN for looking up LDAP users.
	baseDN: ou=users,dc=owncloud,dc=com
	# -- LDAP search scope to use when looking up users. Supported values are `base`, `one` and `sub`.
	scope: sub
	# -- Type of substring search filter to use for substring searches for users. Possible values: `initial` for doing prefix only searches, `final` for doing suffix only searches or `any` for doing full substring searches
	substringFilterType: any
	# -- LDAP filter to add to the default filters for user search like `(objectclass=ownCloud)`.
	filter:
	# -- The object class to use for users in the default user search filter like `inetOrgPerson`.
	objectClass: inetOrgPerson
	group:
	schema:
	# -- LDAP Attribute to use as the unique ID for groups. This should be a stable globally unique ID like a UUID.
	id: ownclouduuid
	# -- Set this to true if the defined `id` attribute for groups is of the `OCTETSTRING` syntax. This is e.g. required when using the `objectGUID` attribute of Active Directory for the group ID`s.
	idIsOctetString: false
	# -- LDAP Attribute to use for the email address of groups (can be empty).
	mail: mail
	# -- LDAP Attribute to use for the displayname of groups (often the same as groupname attribute).
	displayName: cn
	# -- LDAP Attribute to use for the name of groups.
	groupName: cn
	# -- LDAP Attribute that is used for group members.
	member: member
	# -- Search base DN for looking up LDAP groups.
	baseDN: ou=groups,dc=owncloud,dc=com
	# -- LDAP search scope to use when looking up groups. Supported values are `base`, `one` and `sub`.
	scope: sub
	# -- LDAP filter to add to the default filters for group searches.
	filter:
	# -- The object class to use for groups in the default group search filter like `groupOfNames`.
	objectClass: groupOfNames

[PixelJonas]

Ok, so if I want to add an external OIDC Server (Keycloak) I also have to run my own LDAP?
Can run the internal LDAP for the things oCIS is doing? I don't have an LDAP Server running at home and don't need one.

Is there any specific design decision, why oCIS does not use the userinfo endpoint?

[wkloucek]

Ok, so if I want to add an external OIDC Server (Keycloak) I also have to run my own LDAP? Can run the internal LDAP for the things oCIS is doing? I don't have an LDAP Server running at home and don't need one.

Unfortunately this Helm Chart currently only aims at large installations. Therefore there is no option to include the builtin LDAP server when using an external OIDC IDP.

For at-home instances I also would not run all oCIS services in different pods (as this Chart does). For single / double digit user numbers a simpler setup should be sufficient and use less resources. I have a draft of a simpler installation but it would need some adaptions to publish it in this repo. In this setup it also would be quite easy to add an external OIDC IDP.

Is there any specific design decision, why oCIS does not use the userinfo endpoint?

We're using the userinfo endpoint (or at least the user information from the access token, if it's a JWT). But we also need a query-able database of ALL users in the oCIS instance. That is not possible with the userinfo endpoint. And instead of building our own database we went for LDAP because in large installation the users will be stored in LDAP anyways.

For the "auto provisioning" use case (user exists only in the OIDC IDP) we take the userinfo from the IDP and write the user into a LDAP on the first login.

[wkloucek]

I added a ticket for a simple deployment that also allows a flexible way to use an external IDP: #77

[PixelJonas]

ok, so when moving towards a home-based setup I prob. should move to the k8s-at-home owncloud-ocis chart. AFAIK it starts the monolithic server.

Thank you very much. If I can support you in any way regarding OIDC integration or an operator based deployment, please reach out