Client authentication: Best practices on connecting to the registry

[alexisph]

Hi all,

What are the current best practices on connecting to the registry, with respect to client authentication?
I've been reading Red Hat's docs which describe the creation of two OIDC clients: 1) registry-api with bearer-only access type and 2) apicurio-registry with public access type.

In my setup, I have created these two OIDC clients in Keycloak and have also configured LDAP federation for the user database. What does the above configuration mean to applications that want to call Apicurio's API? Do they need to know the registry-api client ID?

Also, as a best practice, should each application which will call Apicurio's API use the same registry-api client_id, or should they have their own client_id and client_secret?

Many thanks,
Alexander

[carlesarnal]

Hi @alexisph, no, client applications don't need to know anything about the registry-api client. For your use case, the expected configuration is that each application that wants to contact Registry should use its own pair client_id/client_secret to interact with the API. If you enable RBAC, you can even assign roles to particular clients so they can perform only certain operations.

[alexisph]

Hi @carlesarnal,

Thanks for the reply.
I have RBAC already enabled. The sr-* roles are mapped from LDAP groups and apps authenticate with their AD credentials.
Also providing client_id and client_secret, in addition to AD credentials works.

Just to make sure I got this right, is it really a best practice for the apps to provide both sets of credentials to the service registry? I would like to avoid storing credentials outside of AD, if at all possible.

Thanks,
Alexander

[carlesarnal]

No, providing the credentials directly to the Registry is not really great practice. You should get the token in the client application and then send it to the Registry instead of providing the creds directly.

[alexisph]

Ah, I realize I worded it wrong. Yes, the credentials are provided to Keycloak and keycloak returns the token.
What I wanted to ask was, if it is best practice to create an OIDC client for every app, taking into account that each app also has a set of AD credentials. The main motivation is to assess if I really need to maintain OIDC clients for every app in Keycloak.
If yes, then what is the purpose of the registry-api OIDC client?

Thanks!

[EricWittmann]

The registry-api OIDC client is the one that the registry server itself uses to validate the KC token. Whereas I think the apicurio-registry is the one used by the UI to perform the standard UI auth flow and obtain an access token. IIRC

Question: are the applications that are accessing the registry API doing on behalf of a user? In other words, if one of the applications creates an artifact, should the owner of that artifact be one of the users from your AD or should it be a service account associated with the application itself?

[alexisph]

Hi @EricWittmann,
Not necessarily. The owner can be a service account.
Currently, my other service accounts are managed by AD, if it makes any difference. I would like to keep this model, if possible.

[carlesarnal]

@alexisph if you're using separated AD credentials, and each app is using itss own set, it is probably ok to re-use the client across your applications. I don't think it's a great practice, but at least you're not sharing credentials across applications.

[alexisph]

I think I've found a secure solution for this issue.

I've been studying the authentication protocols (ref1, ref2) in which a client doing machine-to-machine interaction should use the Client Credentials flow.
This is configured on Keycloak by creating an OIDC client and turning "Service Accounts Enabled" on. The OIDC client is given a Service Account Role, e.g. sr-developer. The client requests a token using, as a minimum, grant_type=client_credentials&client_id=${CLIENT_ID}&client_secret=${CLIENT_SECRET}. No AD user/password is involved in this, as the OIDC client credentials are stored on Keycloak.

In summary:

1. For an actual person to use the registry UI, create an OIDC client named registry-client-ui, with "Access Type" = public and "Direct Access Grants Enabled" = off. Set a specific "Valid Redirect URI" (not *) and "Web Origins" = +
2. Create another OIDC client named registry-client-api, with "Access Type" = bearer-only. This client can only validate tokens, it cannot be used to request a token.
3. Create an OIDC client for a test app/service/machine named for example test-client, with "Access Type" = confidential, "Direct Access Grants Enabled" = on, "Service Accounts Enabled" = on. Generate a client_secret and assign a "Service Account Role" = sr-developer

In this way, an actual person can login with their AD credentials and an app/service/machine can request a token with their OIDC client credentials. It seems there is no way to keep all credentials in AD.

[EricWittmann]

Great summary, thanks @alexisph . I think you're right about client-credentials flow. As far as I know, the only other flow that you could use if you wanted to keep the service account credentials in AD is Resource Owner Password Flow. That flow is typically used if the application is acting on behalf of a user but doesn't support redirect based flows. But I think it is also used in your use-case, where your source of service accounts is coming from another system. Here are a couple of relevant links:

https://www.appsdeveloperblog.com/keycloak-requesting-token-with-password-grant/
https://auth0.com/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow

There are many warnings about this flow, because the assumption is that the client is handling user credentials. In this case it really isn't, it's just providing the AD credentials of the service account.

So you could create a single client in KC and use it for all your service account based applications, with different SA credentials for each.

[alexisph]

Hi @EricWittmann . Thanks for the additional insight. I think the ROP flow could work as well, since, as you mentioned, the application is not really handing user credentials.