[keycloak-user] Incomplete ClientRepresentation returned from /{realm}/clients REST endpoint

[Dmitry Telegin]

Hello John,

Indeed, there is no explicit stripping of the keys from the ClientRepresentation, but the key will be omitted in the case of null value. Probably you've picked a client which has the fields simply unset. Just examine the JSON for some of the internal clients like realm-management, you'll see the fields in place. The only exception is the "secret" field, which should be retrieved via the dedicated /client-secret endpoint.

Cheers,
Dmitry Telegin
CTO, Acutus s.r.o.
Keycloak Consulting and Training

Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
+42 (022) 888-30-71
E-mail: info at acutus.pro

On Thu, 2019-01-31 at 10:50 -0500, John Dennis wrote:
> A GET on the /{realm}/clients REST endpoint is supposed to return an 
> array of ClientRepresentation JSON objects. This is documented here:
> 
> https://www.keycloak.org/docs-api/4.8/rest-api/index.html#_clients_resource
> 
> According to the REST documentation 
> (https://www.keycloak.org/docs-api/4.8/rest-api/index.html#_clientrepresentation) 
> a ClientRepresentation is supposed to contain the following top level keys:
> 
> access
> adminUrl
> attributes
> authenticationFlowBindingOverrides
> authorizationServicesEnabled
> authorizationSettings
> baseUrl
> bearerOnly
> clientAuthenticatorType
> clientId
> consentRequired
> defaultClientScopes
> defaultRoles
> description
> directAccessGrantsEnabled
> enabled
> frontchannelLogout
> fullScopeAllowed
> id
> implicitFlowEnabled
> name
> nodeReRegistrationTimeout
> notBefore
> optionalClientScopes
> origin
> protocol
> protocolMappers
> publicClient
> redirectUris
> registeredNodes
> registrationAccessToken
> rootUrl
> secret
> serviceAccountsEnabled
> standardFlowEnabled
> surrogateAuthRequired
> webOrigins
> 
> However when authenticated as the admin in the master realm on Keycloak 
> version 4.8.2.Final a GET on /{realm}/clients returns 
> ClientRepresentation's containing only these keys:
> 
> access
> attributes
> authenticationFlowBindingOverrides
> bearerOnly
> clientAuthenticatorType
> clientId
> consentRequired
> defaultClientScopes
> directAccessGrantsEnabled
> enabled
> frontchannelLogout
> fullScopeAllowed
> id
> implicitFlowEnabled
> nodeReRegistrationTimeout
> notBefore
> optionalClientScopes
> protocol
> publicClient
> redirectUris
> serviceAccountsEnabled
> standardFlowEnabled
> surrogateAuthRequired
> webOrigins
> 
> This means the following keys are omitted from the ClientRepresentation. 
> Why?
> 
> adminUrl
> authorizationServicesEnabled
> authorizationSettings
> baseUrl
> defaultRoles
> description
> name
> origin
> protocolMappers
> registeredNodes
> registrationAccessToken
> rootUrl
> secret
> 
> As far as I can tell the documented ClientRepresentation closely matches 
> what is in the code here:
> 
> https://github.com/keycloak/keycloak/blob/master/core/src/main/java/org/keycloak/representations/idm/ClaimRepresentation.java
> 
> I believe this is the method used to return the ClientRepresentation 
> from the REST endpoint:
> 
> https://github.com/keycloak/keycloak/blob/885eec5ef2628e41d59f4017745df44e7b519533/services/src/main/java/org/keycloak/services/resources/admin/ClientsResource.java#L98
> 
> The conversion from model to representation occurs here:
> 
> https://github.com/keycloak/keycloak/blob/885eec5ef2628e41d59f4017745df44e7b519533/server-spi-private/src/main/java/org/keycloak/models/utils/ModelToRepresentation.java#L528
> 
> I don't see anything which is dropping the missing keys in the returned 
> ClientRepresentation.
> 
> Is something filtering the result?
> 
> The context for the question arises from this: We were creating a client 
> via a PUT and allowing Keycloak to generate the client secret, we then 
> wanted to extract the client secret from the ClientRepresentation but 
> it's absent. I can also undersand why the client secret might be omitted 
> for security reasons (although I did find that seems to replace that 
> value with "**********", but that's not happening either, it's just 
> absent). That's when we noticed it wasn't just the client secret that 
> was missign but 12 other keys as well.
>