Improve documentation for WebIdentity orphaned keys reclaim

[spomata]

I encountered the same issue described in #17064 when changing the URL of our Keycloak instance which is used as OpenID auth provider in the MinIO setup I have deployed.

I understand that MinIO cannot react to such changes in the OpenID configuration and, as such, the best we can do is generate new access keys: however, in my opinion, it's not clear in the documentation what is the procedure to reclaim back the keys generated prior to the config change, which are invisible to the setup but yet are perfectly functioning.

Is it enough with setting MINIO_IDENTITY_OPENID_CLAIM_USERINFO on?

[ravindk89]

https://github.com/minio/minio/issues/17064#issuecomment-1519040355

So it's just setting https://min.io/docs/minio/linux/reference/minio-server/settings/iam/openid.html#keycloak-admin-url , assuming that the keycloak/OIDC provider supports that URL?

To confirm all we can document here is that:

• For OIDC users who have created access keys, if the OIDC URL changes, those keys become unlinked and unlistable

• Admins need to ensure the UserInfo endpoint is set in MinIO to allow for those access keys to be automatically expired

• Otherwise they are retained until their expiry, if one is set, or indefinitely if not

@donatello are there any other clean ways of removing those dangling access keys beyond UserInfo ? I vaguely recall some confusion on this topic because that URL should be included in the main OIDC .well-known-configuration document, but sometimes it doesn't take.

EDIT: It might be that not all OIDC providers automatically map a users info into the userinfo endpoint. There's not much we can do about that, beyond guidance to ensure those values are configured appropriately.

[ravindk89]

I'll move this to docs if there is no engineering work planned to address the 'reclaim keys' request. If we generally consider those keys are permanently lost, then a docs-only changeup and guidance is sufficient.

[donatello]

For now there is no way to reclaim/list such access keys. We will discuss internally about what could be done, but it may not be a high priority item at this time.

[ravindk89]

Gotcha - I'll open up an independent docs ticket in a bit then, and we can use this to track the overall request.

I think in general we do not tend to support migration of external auth URLs @donatello , we saw similar issues w/ AD+LDAP when the queries changed over time. In that case we were able to handle some of the mappings automatically but it generally gets messy.

I'm leaning towards wrapping in an all-purpose warning to not modify the OIDC / AD+LDAP settings after you have users logging in.

[harshavardhana]

For now there is no way to reclaim/list such access keys. We will discuss internally about what could be done, but it may not be a high priority item at this time.

doing this via MC is cumbersome. That's why it's not done.

[spomata]

#17064 (comment)

So it's just setting https://min.io/docs/minio/linux/reference/minio-server/settings/iam/openid.html#keycloak-admin-url , assuming that the keycloak/OIDC provider supports that URL?

To confirm all we can document here is that:

• For OIDC users who have created access keys, if the OIDC URL changes, those keys become unlinked and unlistable
• Admins need to ensure the UserInfo endpoint is set in MinIO to allow for those access keys to be automatically expired
• Otherwise they are retained until their expiry, if one is set, or indefinitely if not

@donatello are there any other clean ways of removing those dangling access keys beyond UserInfo ? I vaguely recall some confusion on this topic because that URL should be included in the main OIDC .well-known-configuration document, but sometimes it doesn't take.

EDIT: It might be that not all OIDC providers automatically map a users info into the userinfo endpoint. There's not much we can do about that, beyond guidance to ensure those values are configured appropriately.

Thanks for all these insights, they are surely helpful.

I will do some testing on my side enabling the UserInfo claim and making sure it is mapped correctly, expecting those orphaned keys to be automatically expired.

[harshavardhana]

#17064 (comment) So it's just setting https://min.io/docs/minio/linux/reference/minio-server/settings/iam/openid.html#keycloak-admin-url , assuming that the keycloak/OIDC provider supports that URL? To confirm all we can document here is that:

• For OIDC users who have created access keys, if the OIDC URL changes, those keys become unlinked and unlistable
• Admins need to ensure the UserInfo endpoint is set in MinIO to allow for those access keys to be automatically expired
• Otherwise they are retained until their expiry, if one is set, or indefinitely if not

@donatello are there any other clean ways of removing those dangling access keys beyond UserInfo ? I vaguely recall some confusion on this topic because that URL should be included in the main OIDC .well-known-configuration document, but sometimes it doesn't take. EDIT: It might be that not all OIDC providers automatically map a users info into the userinfo endpoint. There's not much we can do about that, beyond guidance to ensure those values are configured appropriately.

Thanks for all these insights, they are surely helpful.

I will do some testing on my side enabling the UserInfo claim and making sure it is mapped correctly, expecting those orphaned keys to be automatically expired.

Going to close this for now as non actionable.