ldap user manager does not fill id, opaque_id and idp

[butonic]

currently lookup of opaque_id and idp in ldap is not possible because it the ldap user provider does not fill them with anything. we at least need to be able to configure the idp. the opaque_id should be configurable by specifying which attrubute from ldap to use. we could split the userPrincipalName or configure two attributes for opaqe_id and idp (which map to sub and iss in openid world).

We should implement an id-strategy so that we can implement different solutions how to look up the id.

warning ... this is only a workaround: there might not be a way to retrieve the oidc sub from ldap.

The correct solution is to implement a new SCIM user manager, because there are idps that support listing users using the SCIM api and there is already a draft OpenID Connect Profile for SCIM Services. Tracked in #327

[labkode]

@madsi1m will provide a configuration option for the LDAP plugin to setup the Idp

[butonic]

We are dancing around the problem that we need a way to persist a user id but the different systems may know the user under different ids:

• The idp generates a sub claim that is unknown to eg ldap
• LDAP generates a uuid like attrubute, but the organization might have introduced
  a custom / different attribute to uniquely identify users, eg the employeeNumber because that does not change on reimports of a user in the ldap tree.
• The storage provider internally might use a numeric uid and gid for file ownership and permissions.

The perfect userid for reva is unique, persistent and non-reassignable. Why?

1. unique, so we can differentiate between two end users called 'Anna Meyer'
2. persistent, so we can identify the user on subsequent logins, even if she marries as 'Anna Müller'
3. non-reassignable, so we treat a new 'Anna Meyer' joining the organization as a different person than the 'Anna Meyer' that left the organization 10 years ago.

Best we can do is keep track of the history uf userids and provide a migration script.

First step to make this technically possible: cs3org/cs3apis#46
It allows the auth providers to return not only return a userid but also other metadata.

[butonic]

Ultimately, we will always need to be able to update the owner and sharing permissions in an easy way. The idea is to have a cli tool that can replace a user or group id and transfer the ownership and share grantees. Tracked in owncloud/ocis#58

Keeping a history of previous ids can be added later, as it only allows deferring the ownership change.

[madsi1m]

it does now

[ishank011]

@labkode @butonic @madsi1m can we look into this now? For OCM, the same opaque_id can be present across mesh providers, but the combination of idp and opaque_id would be unique. So this needs to be implemented for that to work.

[butonic]

outdated