Repository navigation
Client policies: Migration strategy for existing clients #12405
Replies: 1 comment
|
Hello @danielFesenmeyer , Your idea will work well. I have also the following 2 ideas.
If an existing app have some characteristics that an app to be created does not have, we can use it.
On Admin UI, if we modify an existing app, the policy is not applied. If no such role is assigned to an existing app, we would find out other characteristics that only an existing app has, and write our own condition to use the characteristics.
We setup two administrator, the one is for managing existing apps and the other is for
8000
managing apps o be created. For example, the former belongs "legacy" group while the latter not.
On Admin UI with the former admin, if we modify an existing app, the policy is not applied. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hi,
We consider to make use of the "Client policies" feature in order to make sure that our customers' clients are secured appropriately.
Actually we have quite many existing clients, and lots of those don't conform to the PKCE enforcer (we have not checked other enforcers yet).
Ideally, we would like to make sure that new clients are created the proper way (i.e. conform to the policy), whereas existing clients still work as before, until the corresponding applications have been migrated (e.g. to support PKCE).
But the question is how we can achieve this?
The first thing I thought of was to configure a client-updater-context condition for the policy (with all available Update Client Contexts). This way, the policy would only be applied, in case of client creation or update, not on any other events such as authorization requests. The PKCE enforcer would be configured with auto-configure disabled, to avoid clients to be updated with the PKCE setting, in case something unrelated is changed (like the displayName) - cause this could break existing applications.
But the downside is that with this configuration, via the Admin UI (both V1 and V2), clients can no longer be created - because the UI always first creates an "incomplete" client, which can then be further configured by the user. With auto-configure=false, the creation of this "incomplete" client fails. Is this a bug or expected behavior? Wouldn't it be better if the whole client would be created with a single request?
To fix the UI's client creation problem, we could set auto-configure=true for the PKCE enforcer. But as mentioned above, this would lead to automatic configuration of the PKCE setting, in case of any unrelated update of the client, and might break existing applications.
Another idea would be to implement our own condition, which just applies to client creation (NOT update). This condition could be replaced with an any-client condition, as soon as all applications have been migrated.
WDYT?
All reactions