Feature - Please add support for additional displayed username and make persistent volume names more robust

[alternone]

Currently the mapped username from identify provider will be used for several use cases with some limitations:

• username will be displayed
• username will be used for creation of persistent volumes
• username will be used for access control
• ... maybe more

This leads to some issues.

• persistent volumes with real names lead to issues due to special characters like white spaces (this should be considered and made more robust (by e.g. always use internal user ID instead or escaping characters of usernames)
• additional fields should be synced from identity manager like real names or Email-address beside internal company IDs. A second value would allow to define a display name which is more helpful for user access management and access checks.

Thus I would recommend to support 2 or 3 synchronization fields for identity managements:

• identification field : to map company internal IDs and to be used for persistent volumes and unique IDs
• name field: to map real names for UI displaying in profiles and access control
• e-mail field: for possible upcoming features like mail notifications (from e.g. jobs) , announcements, access invites

PS: I agree for persistent volumes a migration script is required tp upgrade existing persistent volumes when switching to a version that has a different mapping caused by this feature.

[MoritzWeber0]

Hi @alternone,

thanks for the feature request. Definitely valid points.

persistent volumes with real names lead to issues due to special characters like white spaces (this should be considered and made more robust (by e.g. always use internal user ID instead or escaping characters of usernames)

A good first step will be to save a reference to the name of the PVC to the database. That's only a small database migration script. Currently, the persistent volume name is derived from the username on demand as you've mentioned. A saved reference in the database would allow us to change the naming algorithm of PVCs without the need to migrate "old" PVCs. Old PVCs can keep their name and new persistent volume claims can then use new naming algorithm.

The idea of having different fields aligns with our strategy.

identification field : to map company internal IDs and to be used for persistent volumes and unique IDs

I'd only use the identification field to map the user from the identity provider to our internal user. For persistent volumes, I would not rely on external values. Instead, I'd use a randomly generated ID or our internal user database ID for the PVC name.

name field: to map real names for UI displaying in profiles and access control

Makes sense to have a different field for display name.

e-mail field: for possible upcoming features like mail notifications (from e.g. jobs) , announcements, access invites

👍

[MoritzWeber0]

Implemented in #1652 and #1653