Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client scopes aren't deleted when removed from the JSON configuration #1232

Open
mtthwcmpbll opened this issue Dec 9, 2024 · 0 comments
Open
Labels

Comments

@mtthwcmpbll
Copy link

mtthwcmpbll commented Dec 9, 2024

Current Behavior

When I run the keycloak-config-cli against a configuration that changes or deletes a clientScope previously present in the JSON config, that client scope is not deleted or modified.

Expected Behavior

Reading through the MANAGED documentation, I expected the scope that was originally created to have metadata that allowed keycloak-config-cli to identify that something changed and update or delete that client scope as appropriate. As it stands, if I delete the clientScope, the previously-created scope remains unchanged. If I change the name, it just adds a new second scope with the new name and leaves the original in place as well.

Steps To Reproduce

  1. Create a configuration in a file conf/01_realm.json that creates a new Realm with one client scope:
{
  "enabled": true,
  "realm": "test-realm",
  "displayName": "Test Realm",
  "displayNameHtml": "<div class=\"kc-logo-text\"><span>Keycloak - ${role_uma_authorization}</span></div>",
  "verifyEmail": false,
  "notBefore": 0,
  "browserSecurityHeaders": {
    "contentSecurityPolicyReportOnly": "",
    "xContentTypeOptions": "nosniff",
    "xRobotsTag": "none",
    "xFrameOptions": "SAMEORIGIN",
    "contentSecurityPolicy": "frame-src 'self'; frame-ancestors 'self'; object-src 'none';",
    "xXSSProtection": "1; mode=block",
    "strictTransportSecurity": "max-age=31536000; includeSubDomains"
  },
  "clientScopes": [
    {
      "name": "test.component.admin",
      "protocol": "openid-connect",
      "attributes": {
        "include.in.token.scope": "true",
        "display.on.consent.screen": "true",
        "consent.screen.text": "Administrator access to all Components"
      }
    }
  ]
}
  1. Apply the configuration with the docker version of the CLI:
docker run --rm -ti \
  -v $PWD:/config/ \
  -e LOGGING_LEVEL_ROOT=INFO \
  -e LOGGING_LEVEL_KEYCLOAKCONFIGCLI=DEBUG \
  -e LOGGING_LEVEL_HTTP=DEBUG \
  -e LOGGING_LEVEL_REALMCONFIG=DEBUG \
  -e KEYCLOAK_URL="https://my.test.keycloak.com/" \
  -e KEYCLOAK_GRANTTYPE="client_credentials" \
  -e KEYCLOAK_CLIENTID="keycloak-automation" \
  -e KEYCLOAK_CLIENTSECRET="***************************" \
  -e KEYCLOAK_AVAILABILITYCHECK_ENABLED=true \
  -e KEYCLOAK_AVAILABILITYCHECK_TIMEOUT=15s \
  -e IMPORT_FILES_LOCATIONS='/config/01_realm.json' \
  -e IMPORT_VARSUBSTITUTION_ENABLED=true \
  -e KEYCLOAK_VERSION=25.0.6 \
  -e MAVEN_CLI_OPTS="-B -ntp -q" \
  -e IMPORT_REMOTESTATE_ENABLED=false \
  adorsys/keycloak-config-cli:latest-25
  1. Verify that the new realm "Test Realm" is created and has the provided scope "test.component.admin" - it does!
  2. Rename the scope in the 01_realm.json file to "test.component.admin2" and rerun the docker command to apply it
  3. Check again, and there are two scopes, "test.component.admin", and "test.component.admin2"

I've also tried deleting the scope from 01_realm.json leaving just clientScopes: [] (which my understanding of MANAGED docs means it should delete all managed clientScopes) but this doesn't do anything to the scopes previously created.

Environment

  • Keycloak Version: 25.0.6 (also checked with the latest v26 release)
  • keycloak-config-cli Version: docker tag latest-25 (also checked with latest-26)
  • Java Version: Uncertain, as I'm running an instance of Keycloak deployed using the Keycloak Operator inside a kubernetes cluster

Anything else?

No response

@mtthwcmpbll mtthwcmpbll added the bug label Dec 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant