fix: allow to delete a relyingPartySecret on IdP #2885
Conversation
Extract the delete change into an own PR, because this missing method is really a bug / issue in UAA. A UAA operator cannot remove a secret currently, but there are situation where this is needed, e.g. public flows or change to private_key_jwt.
|
We have created an issue in Pivotal Tracker to manage this: https://www.pivotaltracker.com/story/show/187592987 The labels on this github issue will be updated when the story is started. |
server/src/main/java/org/cloudfoundry/identity/uaa/provider/IdentityProviderEndpoints.java
Outdated
Show resolved
Hide resolved
|
Instead of offering a new |
…n IdP Alternative to PR: #2882, #2887 and PR: #2885 Only one call in backend, but more input on client side. authMethod is used to make this change non-breakable. Because before the update prevented the removal of the relyingPartySecret. No if authMethod is not client_secret_basic or client_secret_post, then the relyingPartySecret can be overwritten with null.
ok, so I created another alternative PR, see #2896 This PR #2896 is introducing a new attribute "authMethod" and with this the change is non-breakable, but an enhancement. Without authMethod the secret is still retrieved from existing DB setting. |
|
Thanks! I prefer the alternative, so let's move our discussion there (#2896). |
…n IdP (#2896) * WIP: idp secret * feature: delete secret on existing IdP - allow to delete a relyingPartySecret on IdP - Filter IdP list by origin - Return the auth_method to show current configured client authentication method * Documentation * fix names * sonar * sonar * Add patch call to change a secret from an external IdP * Alias handling * 2nd alternative fix: allow to change or delete a relyingPartySecret on IdP Alternative to PR: #2882, #2887 and PR: #2885 Only one call in backend, but more input on client side. authMethod is used to make this change non-breakable. Because before the update prevented the removal of the relyingPartySecret. No if authMethod is not client_secret_basic or client_secret_post, then the relyingPartySecret can be overwritten with null. * sonar * Tests added * Sonar smell * Review * more checks for edge cases * more tests to cover edge cases * Review Again fixed an edge case CLIENT_SECRET_BASIC, CLIENT_SECRET_POST both same method, therefore treat them equal * Review Again fixed an edge case Found during tests * Test refactored * small doc fixes - some clarification & formatting - no need to call out what the default is in the description because the `.optional("client_secret_basic")` syntax would automatically add that language. * doc: clarify when external OIDC client auth requirements - clarify when config.jwtClientAuthentication and config.relyingPartySecret are required in relation to the new field config.authMethod * Review, removed auth_method which is not used, but we ue authMethod field only * revert this * remove deprecated --------- Co-authored-by: Peter Chen <peter-h.chen@broadcom.com>
|
close because we used #2896 |
Extract the delete change into an own PR, because this missing method is really a bug / issue in UAA. A UAA operator cannot remove a secret currently, but there are situation where this is needed, e.g. public flows or change to private_key_jwt.
Example to delete a secret, e.g. from DOC:
curl 'http://localhost/identity-providers/ba820e42-7bbf-445a-a241-bb49d61b8512/secret' -i -X DELETE
-H 'Authorization: Bearer 8b8a49f6186d4995af427ea59b40e8f8'