OCHTTPStatusErrorDomain because new generic KeyCloak Client is being created for each login from Desktop/iOS/Android

[walt-jones]

Pre-submission Checks

• I checked for similar issues, but could not find any. I also checked the closed issues. I could not contribute additional information to any existing issue.
• I will take the time to fill in all the required fields. I know that the bug report may be dismissed otherwise due to lack of information.

Describe the bug

We're currently blocked by an issue where every time ownCloud Desktop/iOS/Android attempts to authenticate with KeyCloak a new generic Client is created without any of the settings we've put into the one that Desktop/iOS/Android are supposed to be using. This results in access being blocked and a OCHTTPStatusErrorDomain error in ownCloud Desktop/iOS/Android.

Additional detail: We have a custom token mapper on our clients that’s required for proper assignment of roles in oCIS. Works great in ocis-web and we have this on the clients for ownCloud Desktop and ownCloud iOS/Android… but when someone goes through auth for these clients they always get a new Client spawned in KeyCloak that has none of our configurations. It’s already super messy having thousands of extra Clients being automatically generated, but not having them inherit our setup from the base Clients means they’re unusable.

We found a rather painful workaround where if you know the ID of the automatically spawned Client you can quickly jump in as a KeyCloak admin, manually add the right configs and then quickly go through auth again. Not viable in production, of course, but it proves the issue is with these autogen’d Clients.

See https://central.owncloud.org/t/a-new-client-is-being-created-for-each-login-with-keycloak/50789 for more detail and history on this.

Expected behavior

There should be only one Client in KeyCloak for ownCloud Desktop, iOS and Android that we have control over to configure as needed. There should not be a OCHTTPStatusErrorDomain error when connecting.

Steps to reproduce the issue

No response

Screenshots

Logs

No response

Client version number

ownCloud Desktop 5.3.1.14018
ownCloud iOS 12.3.1
ownCloud Android 4.4.0

Desktop environment (Linux only)

No response

Client package version and origin (Linux only)

No response

Installation path (Windows only)

No response

Server information

No response

Additional context

No response

[TheOneRing]

Have you tried to disable dynamic registration and to register the client id and secret hard-coded into the client, with keycloak?

[Schmagz]

Have you tried to disable dynamic registration and to register the client id and secret hard-coded into the client, with keycloak?

We have the same problem and it doesn't matter if a client with ID and secret is setup correctly, a new client is always being created for each login.

[TheOneRing]

Your idp well-known has a registration_endpoint therefor the client uses it by default.
Disabling it in the client is currently only possible via branding, I recommend registering the client as described in my previous post and to adjust your wellknown entry.

[micbar]

Please disable dynamic client registration on your keycloak if you want to use the public client id and secret.

Do you know how to do it?
I did it on an earlier version of keycloak and it has not been intuitive 😅

[micbar]

Some background https://www.keycloak.org/securing-apps/client-registration

[butonic]

AFAICT dynamic client registration should create a new client on the first authentication. That works as designed. The client should not register a new client until the refresh token expires and the IDP forces the user to reauthenticate. If that was the case I'd see it as a bug. Otherwise ... see if we misunderstood https://openid.net/specs/openid-connect-registration-1_0.html

[Schmagz]

It could be a bug but I'd like to try if the method with disabling dynamic client registration works, do you remember how you did it @micbar? I've looked under "Client registration" under "Client" or "Client policies" under "Realm Settings" but no settings seems obvious but it could just be non-intuitive like you said :)

[micbar]

I think I achieved my goal by blocking the redirect url of the client in „client policies“.

[Schmagz]

Do you know if Keycloak still tries to access url even though it's blocked? Why I'm asking is because we have limited the number of Clients that are allowed to be created in Keycloak as a temporary solution for this issue but Keycloak still sends our WAF a 403 error every 4-5 minutes for each client and user resulting in IP blocks and filling logs with false positives which is not a good solution.

[walt-jones]

We’d like to try the proposed solution disabling dynamic client registration. Looking over docs it’s definitely not straight forward as also mentioned above. Any guidance on how to approach this would be greatly appreciated.

[github-actions]

This issue was marked stale because it has been open for 30 days with no activity. Remove the stale label or comment or this will be closed in 7 days.

[walt-jones]

Ping

[mitexleo]

Still searching for a solution.

[walt-jones]

We stumbled upon https://github.com/cevheri/keycloak-custom-event-listener as a potential (and still somewhat hacky) workaround for this. Really we just need a way to get back the old ownCloud Desktop and ownCloud Mobile behaviors that didn't spawn a new Client every time someone attempts to authenticate. We're dead in the water on being able to use any of the ownCloud clients until we figure out a way to stop this new behavior.

[micbar]

I do it like #11940 (comment)

[walt-jones]

Thanks @micbar. Can you share details on how you did this? We have a saml-avoid-redirect executor type but it seems to have no effect on the flow and there's no obvious way for us to assign it to particular clients.

[Schmagz]

I do it like #11940 (comment)

Can you please tell where in KC this is done? I searched when you first suggested it but could't find how to implement it.

[walt-jones]

@micbar can you advise on the details of your solution to this?

[micbar]

Solution for Keycloak 25

1. Enter Keycloak Admin Menu
2. Click Clients
3. Go to Tab "Client registration"
4. Click "Create client policy"
5. Click "trusted hosts"
   
6. Leave "Trusted Hosts" field empty
   

Effect

This prevents clients from registering them with their random client ID and forces them to use the preconfigured clients from https://github.com/owncloud/ocis/tree/master/deployments/examples/ocis_keycloak/config/keycloak/clients

[walt-jones]

Solution for Keycloak 25

1. Enter Keycloak Admin Menu
2. Click Clients
3. Go to Tab "Client registration"
4. Click "Create client policy"
5. Click "trusted hosts"
6. Leave "Trusted Hosts" field empty

Works! Seriously amazing, @micbar - thanks for breaking this down!

[Schmagz]

@micbar @walt-jones How does your KC log look like? Every 5 minutes Keycloak logs these errors not being able to register client, it's the same as blocking number of clients allowed:

2024-12-10 18:16:49,145 WARN  [org.keycloak.services] (executor-thread-4) KC-SERVICES0101: Failed to verify remote host : XX.XXX.XXX.X
2024-12-10 18:16:49,146 WARN  [org.keycloak.services] (executor-thread-4) KC-SERVICES0099: Operation 'before register client' rejected. Policy 'Block Client Registration' rejected request to client-registration service. Details: Host not trusted.
2024-12-10 18:16:49,146 WARN  [org.keycloak.events] (executor-thread-4) type="CLIENT_REGISTER_ERROR", realmId="bdf56398-30a5-446b-999c-9e4915fc4c4c", realmName="ocis", clientId="null", userId="null", ipAddress="XX.XXX.XXX.X", error="not_allowed", client_registration_policy="Block Client Registration"

Resulting in our WAF blocking our IPs

10/12/2024 18:16:49 XX.XXX.XXX.X POST /realms/ocis/clients-registrations/openid-connect 403 Mozilla/5.0 (Windows) mirall/5.3.1.14018 (ownCloud, windows-10.0.22631 ClientArchitecture: x86_64 OsArchitecture: x86_64) unknown {}

[Schmagz]

@micbar What I'm trying to say is that we already had the same temporary solution by blocking number allowed clients but it gives other problems and is not a solution of this problem. Why is owncloud clients not using the correct clients by default? Will this be fixed in a future update?

[micbar]

@Schmagz
The owncloud clients are looking at the capabilities of the identity provider. When keycloak provides a registration url, they will use it and fall back to the default client if that fails.

The reasoning behind that is, many people do not want to use the public client id and secret. So client registration is considered more secure. This is the reason why the clients try that first and then fall back to the public clients.

I must admit that the error log is ugly but to be honest, keycloak should solve this better. When the server announces a registration feature, the clients will use it. Blocked by policy is IMHO not an error log, because that is expected to happen during normal operations.

[Schmagz]

Thank you for that detail answer. I don't mind the big log file the problem is that our WAF easily block our IPs but I will look into how that can be solved instead.