Skip to content

Authentication and autorization

Problem

All clients share the same username and password. Given these credentials client1 can see configuration for client2. This affects /client/registration and /client/{clientId}/sync.
This becomes a problem if clients are preregistered and simple/natural clientIds are used. An attacker with access to the shared username/password can then guess the clientId and get access to another party's ApplicationConfig.

Roles and access control

Path Access Comment
/health Anonymous
/client/registration Shared client registration/sign-up credentials ConfigService Client API, login.user/login.password
/client/{clientId}/sync client credentials ConfigService Client API, clientId/clientSecret
All other paths admin ConfigService Admin API, login.admin.user/login.admin.password

TODO: CS Dashboard should be possible to set up CS Dashboard with a user which cannot change any data OR a user with rw privileges to enable admin features from CS dashboard.

How does it work

  1. When a new Client is created, a clientSecret string is set using UUID.randomUUID().
  2. /client//registration, the clientSecret is returned to the client and persisted using ConfigServiceClient.saveApplicationState. The clientSecret is afterwards included whenever the client checkForUpdate (client/{clientId}/sync).
  3. PUT /client/{clientId}
  4. The clientSecret is validated when a client calls client/{clientId}/sync. This validation is off by default, but can be enabled with the property client.secret.validation.enabled.

Implementation notes

  1. Backward compatible: It should be possible to continue to support the existing behavior. I.e.,
  2. Read login.admin.user and login.admin.password from configservice.properties and create or update these credentials in the database. All permissions for all paths.
  3. Read login.user and login.password from configservice.properties and create or update these credentials in the database. Access to /client.

  4. Extend Preregister Client with specific ApplicationConfig to also create a user with username=clientId and generate a password if password is omitted?

  5. Write clientSecret

  6. ClientResource.registerClient (ClientService.registerClient)
  7. ClientAdminResource.putClient
  8. Read
  9. ClientResource.sync
  10. Perstence client side
  11. clientSecret is returned from ClientResource.registerClient (in ClientConfig) and persisted by ClientService.saveApplicationState
  12. Client secret validation check is feature-toggled using property client.secret.validation.enabled

Suggestion

Note! Current implementation does not use Spring Security or SQL db.

Dependencies