Cleanup UAA Client Secret Setting and Ensure Authentication on Client Credentials Grant Flow

[strehle]

The setup of clients in UAA can be done based on uaa.yml in a CF landscape, then there is no real validation if a client has no secret or an empty secret and you can do everything... also dangerous things.

Dangerous means: You setup a client with authorized grant type "client_credentials" and you create a client token with an empty secret, e.g. cf client could be upgraded via REST.
The normal case is, you create a client within UAA based on REST Endpoint
https://cloudfoundry.github.io/uaa/version/77.24.0/index.html#create-4

Here we have validation, done in class
ClientAdminEndpointsValidator

The validation means

• client credential client must have authentication - until now only secrets covered. -> https://github.com/cloudfoundry/uaa/blob/develop/server/src/main/java/org/cloudfoundry/identity/uaa/client/ClientAdminEndpointsValidator.java#L238-L243
• JWT bearer must have secret -> https://github.com/cloudfoundry/uaa/blob/develop/server/src/main/java/org/cloudfoundry/identity/uaa/client/ClientAdminEndpointsValidator.java#L147-L149

The validation in the REST endpoint is a problem because it cannot check cover all parts, because with these calls

uaac client add uaa-client --name test --authorized_grant_types password --scope "openid test.read test.write" -s ""
uaac client update uaa-client --authorized_grant_types "client_credentials urn:ietf:params:oauth:grant-type:jwt-bearer"
uaac token client get uaa-client -t -s ""

You can setup a client with an empty secret and a JWT bearer grant with an empty secret.

JWT bearer with an empty secret (or without secret if allowpublic) is no issue - at least to me, because for JWT bearer you must bring a trusted assertion, so there is an authentication. Password grant is allowed with empty secret, and I dont see that much diferences between password grant and jwt bearer grant.

About client_credentials. This flow must not allow authentication without a secret or with an empty secret.

The issue should:

• Start discussion about client authentication. To me it must be checked during the grant flows and not in REST . An authentication can be private_key_jwt and not only secret, but empty secret is an authentication we should not set on the same level as e.g. private_key_jwt
• Track fixes about check of client authentication mechanism