Keep track of previous userids

[butonic]

The CS3 API is using a so called scoped identifier to distinguish users. The UserId consists of an idp and an opaqueid. Which maps to the openid iss and sub, the only thing the oidc spec says that can be used to identify a user.

I have to disagree.

The oidc core spec uses URLs as identifiers for the iss. While the combination of sub@iss is described as unique, in reality the iss can change easily, eg. in case of a rename of the company due to a merge or a legal issue. We are already seeing that at customers.

There is a related spec from the MODRNA WG: OpenID Connect Account Porting covers migrating a user from one idp to another. AFAICT the spec fails to capture the scenario of multiple migrations. It expects the two idps to do an active handover and be cooperating. The user might still loose access to his account at a relying party, such as OCIS, in case he can no longer log in with his old idp.

AFAICT an openid relying party, such as reva or ocis, should keep a history of sub@iss userids. We can use it to check grants in storage providers, that will still work when a user has a new sub@iss because the storage provider can also check previous sub@iss entries in the id history.

It will also allow us to do a clean migration of users between instances. Or when turning a guest account into an internal user.

There is a security impact: an attacker can gain access to a user by adding a sub@iss combination of another user to his user id history. That prevents this mechanism to be used for a user triggered im / export, unless we use signatures and private keys, which then need to be stored in a secure way, and need to be tied to the web of trust ... urgh ... nomadic identities basically. There is hubzilla, W3C DIDs and a great discussion with a lot of insight into pros and cons. We can limit adding previous userids to a user history to the admin for now.

This is btw how MS does it in their active directory and with the SID and sidHistory ldap properties. They also have a kb article on inter forest sidhistory migration

The sid history in AD should be cleaned up, which can be done by updating all grants with the new sub@iss value. See Sneaky Active Directory Persistence #14: SID History. The distributed nature of ocis make this a lot harder.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[refs]

Should we write an ADR for this as a next step @butonic ?

[butonic]

We moved to an approach that reads a custom ownclouduuid claim which can be migrated to a different IdP. The ADR as well as the devdocs should cover why we have this ownclouduuid, how it can be configured if a claim with the same properties is already available and if it needs to be sent as a claim or if looking it up in ldap is good eough.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[fschade]

Please open again if the ticket is still relevant