This is a common pattern for companies using Kerberos, and that it would be a common requirement from financial institutions.
Here's why this is necessary; a "SCIM" user does not have access to the data itself and also should not have the ability to add credentials to new accounts. Because Kerberos is handling account credentials outside of the database, users will be able to properly authenticate without the SCIM user defining passwords for their accounts. Therefore, if the SCIM user is compromised and a bad actor creates a new account with privileges to read/write arbitrary data, they will not actually be able to log into the account they created without properly authenticating through Kerberos.
This is a common pattern for companies using Kerberos, and that it would be a common requirement from financial institutions.
Here's why this is necessary; a "SCIM" user does not have access to the data itself and also should not have the ability to add credentials to new accounts. Because Kerberos is handling account credentials outside of the database, users will be able to properly authenticate without the SCIM user defining passwords for their accounts. Therefore, if the SCIM user is compromised and a bad actor creates a new account with privileges to read/write arbitrary data, they will not actually be able to log into the account they created without properly authenticating through Kerberos.
Jira: CRDB-1663
Zendesk: 6720
The main pieces of work we've identified would be to:
gz#6720
Jira issue: CRDB-2848