Search user before provisioning (potentially trigger Ldap sync)

[julien-nc]

Call userManager->search($uid) before checking if a user exists when non-auto provisioning. In case user is provisioned by user_ldap, it will perform the Ldap search and get the user even if it was not there before the login.

This way we make sure non-auto provisioning works with recently added users.

[juliusknorr]

Code makes sense.

@blizzz Do you see any noticeable downside of performing that search during every login?

[julien-nc]

@juliushaertl I think user_ldap performs the search on every login if it handles direct login. This is why freshly created Ldap users can immediately log in Nextcloud with direct login.

[julien-nc]

The difficult aspect of this is that admins should be careful and correctly setup user_ldap's login search query and "Internal username" so it matches the Oidc user ID attribute.

[juliusknorr]

I think on a regular ldap login it performs a bind that would sync the user, which might be way faster than performing a search query.

[julien-nc]

This solution does not work if the mapped attribute for user ID is entryUUID because user_ldap appends a wildcard in the search filters which does not works for entryUUID.

nextcloud/server#32499

@juliushaertl I agree it would be nicer if we find a cleaner and faster way to make sure the user is "synced" when logging in with Oidc. We could maybe check if the Ldap backend is "active" and call a public method of it...but which one? 😁

[blizzz]

@juliushaertl I think user_ldap performs the search on every login if it handles direct login. This is why freshly created Ldap users can immediately log in Nextcloud with direct login.

user_ldap does it differently (using login filters and attributes), but user_saml acts like this for the same reason.

[julien-nc]

@juliushaertl I tried calling the userExistsOnLDAP method on the user backend but as we suspected it does not get "new" users (which exist in Ldap but not locally).

@blizzz @juliushaertl The only way I found to "force" the Ldap user backend to get new users is by running this during the Oidc login:

$backends = $this->userManager->getBackends();
foreach ($backends as $backend) {
	if ($backend instanceof \OCA\User_LDAP\User_Proxy) {
		$backend->getUsers('', 100000);
	}
}

It's not pretty but do we really have another option? 😁

[blizzz]

It's not pretty but do we really have another option? grin

https://github.com/nextcloud/user_saml/blob/master/lib/UserResolver.php#L44-L46

which just does a search against user manager

https://github.com/nextcloud/user_saml/blob/master/lib/UserResolver.php#L82-L84

getting 100k (why 100k) from ldap user backend would be bad, performance wise. You don't want to do it in a user facing code path. The user search is already not ideal, but way better.

[julien-nc]

@blizzz Thanks for the feedback. Then I think we should go with the search.

@juliushaertl If the Ldap search is fixed like suggested in nextcloud/server#32499 then we're good here too.

[juliusknorr]

Maybe Ldap -> LDAP and Oidc to OpenID Connect

Other than that maybee we should make it clear that you cannot just change the internal username for an existing setup, so maybe we recommend to map the OIDC app to the existing internal username instead.

[juliusknorr]

Fine with me code wise then, just a small comment on the README docs