Repository navigation
Replies: 9 comments 19 replies
|
I saw in the other discussion you are going to implement hashed client secrets (#8455). In the policy case the expiration and creation happens in a background task right? How does this go along with hashed secrets? Will they be promoted as a special Event or pushed in a transaction to webhook target or something like that? How do external systems get aware of the new secret in this case? Will hashed secrets only work in a "external" secret store case than? And will the API create the secret in the external store but keep only a hash for keycloak locally. I may got a bit confused and I am totally on the wrong page here. |
|
Yes, I am wondering about have the settings of Using client policies can mean that different clients in the realm can have different settings (EG. client secret rotation is disabled for some clients and enabled for different clients). |
|
Yeah, I like that. Let's not have a realm level config, and just make this a client policies thing. |
|
Thank you all, think I got it now after looking at the structure of client policies.
|
|
I was wondering where exactly the border between client policies and client types will be? Looks like they can do similar things… |
|
in case of multiple thousands of clients would it be feasible to have client group policies for that? |
|
There is one small thing, which looks to me a bit cumbersome. That is the case when you use OIDC client registration and at the same time, you have client secret hashing enabled. As we discussed in the morning and you pointed in the example, this won't work with client GET request, which won't be able to return plain-text secret due the fact it is hashed. Hence client will need to use "client update" request. And that thing looks bit cumbersome to me due the fact that "Client update" request will need to copy all the other JSON stuff of the client. The specification https://datatracker.ietf.org/doc/html/rfc7592#section-2.2 mentions: So client will effectively need first call "GET" to return the current client JSON data and then call "UPDATE" with same JSON data just to enforce client secret rotation and return new client secret. I am just pointing this, but I don't have any better idea to solve this. It seems the periodic client secret rotation with client secret hashing is just not ideal combination ... :-/ |
|
In addition to the update possibility specified by the standard, a PUT on sub-resource could be supported. With the data from the example at https://datatracker.ietf.org/doc/html/rfc7592#section-2.2 this would look like this: It's also a pattern which could help at other places where GET/PUT is needed to retain all data in case of an update (e.g. user attributes, realm attributes) |
|
Well, currently we return client secret from GET requests. I don't see any issues with that as both client registration [1] and client management [2] supports returning client secrets and contain examples with With client secret hashing enabled, we will need to skip returning secrets. But as I mentioned, I don't have any better proposal for the case when hashing is enabled... In fact, enabled hashing means, that administrator with rights to [1] https://openid.net/specs/openid-connect-registration-1_0.html#ReadRequest |
This sub-resource PUT approach is maybe something to consider for the new Keycloak admin REST API. In this particular case, it likely won't help much as OIDC/OAuth2 specifications prescribes how the CRUD requests look like and there is not sub-resource approach supported AFAIK |
|
I assume there aren't many vendors anyway who make use of the RFC7592 for client management but rather many operated setup where a team needs to implement a manual or automated process for setting a new secret. An additional endpoint will not break standard compatibility and it would be usable for to set a new secret in a convenient way. |
|
Yeah, I see. However in cases when people does not need to be OIDC specs compliant, it is likely better idea for them to use Admin REST API directly? AFAIK the new admin REST API plans to have something like your idea for sub-resources. Regarding old admin REST API, it already has an endpoint for update only client secret. This is the endpoint, which is currently used by admin console when you go to My original point was related to those cases when people needs to be OIDC specs compliant and hence need to use endpoints described in the specification. |
|
@stianst I have one more additional question when reading more through this: How will Keycloak determine if client-update request should rotate secret or not? For example OIDC dynamic client registration specification does not allow to provide your own "client-secret" and it does not have any way to tell the server if secret should be rotated or not during update request. One possibility is to rotate client secret during each client update request. But this is not ideal as administrator often wants to update client without need to always update client secret. Better possibility is to introduce another option to "client secret policy" to control the timeout, which specifies that client update request will update the client secret just if current secret has low time to expiration. Something like One example how it can work,
WDYT? |
|
Assuming we have one client application running on multiple target hosts doing whatever they need to do. How would that be handled, how do multiple service instances update their shared client secret together? Is there a need to have two expiration times? Are clients supposed to update their own secrets or is that a third party application that is supposed to do that? RFC :) |
|
Could Keycloak have the same approach as azure? e.g.: Instead of single secret the have a list of them, so it's easy to generate a new one and then update client application when possible. Then the have that expire date, but they don't really expire the secret (this could potentially stop productive applications). It's more like a warning for you to take some action and change the current used secret. |
|
I understand that one of the reasons to enable client secret rotation is security and simplicity. The concern that an eventual leak of the client secret will be quickly mitigated. Keeping multiple versions of client secrets can be a challenge for an administrator and I think that once the secret has been rotated it should have a short enough lifetime to expire and somehow force applications to update the secret in use. Please take a look at https://github.com/keycloak/keycloak-community/blob/main/design/client-secret-rotation.md and see how we implement this functionality. Suggestions and contributions are always welcome. |
|
@marcelomrwin of course the security concerns about keeping multiple key versions indefinitely are reasonable, but I think that Keycloak should give also the option of a simple key rotation like in azure (or e.g. in AWS IAM user credentials). too many times security policies fall from above without considering many common use cases that at least in some environments do not pose any risk. for example think about the old discussion on supporting wildcards in the redirect urls. it should be ultimately an admin choice, not a developer one, to accept a marginally less secure configuration if the use case calls for it. |
|
I mean, the current approach would even be more than acceptable if we had the option to never expire the current (new) secret. |
|
created pull request client-secret-rotation, allowing no expiration for new secret #12937 |
|
Is this ever going to come out of |
|
Hello, Is there any timeline for when this secret-rotation goes from preview to production-ready feature? Thanks |
|
Hey @ramalalc, I completely understand your position. To be honest, I know of cases where this functionality has been used in a production environment for some time without any issues. Community engagement is necessary to validate and provide sufficient data for the project maintainers to prioritize this feature. Unfortunately, there aren't many professionals available, and you can imagine the large number of requests and features that are gaining priority. The "preview" label doesn't necessarily mean the functionality can't be used. I recommend testing and validating it in your environment, and if it proves useful, then use this functionality. Unless you are a user of the enterprise version, in which case you will not receive support from the manufacturer while the feature is in preview. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
This proposal is a different take on supporting rotation of client secrets (#8475). In the previous proposal the client secret rotation was handled at the client update APIs, while in this proposal it is a realm level policy.
https://github.com/keycloak/keycloak-community/blob/main/design/client-secret-rotation.md
All reactions