[BUG] Add Option to Disable Sorting of compositeRolesRefs in Keycloak Provider

[yoelpadronglez]

Metadata

• keycloak version: 26.4.2
• crossplane version: 2.1.0
• keycloak provider version: 2.10.1

Reproducible example

When a list of compositeRolesRefs are specified in the role.role.keycloak.crossplane.io manifest, from version 2 this list is sorted according to role UUID value.

Given this example

apiVersion: role.keycloak.crossplane.io/v1alpha1
kind: Role
metadata:
  name: admin
spec:
  forProvider:
    clientIdSelector:
      matchLabels:
        upbound.io/name: springboot-app
    compositeRolesRefs:
      - name: read
        policy:
          resolution: Required
          resolve: Always
      - name: write
        policy:
          resolution: Required
          resolve: Always
    description: Springboot
    name: admin
    realmId: myrealm
  managementPolicies:
    - '*'

What do you expect?

I expect that the keycloak provider can populate the compositeRoles list with the ids but without sorting the existing compositeRoleRef list originally provided in the manifest.

What is the error?

Since the Keycloak operator is modifying the original manifest, I have an unsync issue with my deployment tool(ArgoCD). After running kubectl diff -f template.yaml, I detect that the operator changed the order of the compositeRoleRefs list.

     compositeRolesRefs:
-    - name: write
+    - name: read
       policy:
         resolution: Required
         resolve: Always
-    - name: write
+    - name: read
       policy:
         resolution: Required
         resolve: Always

Given that role IDs in Keycloak are UUID values, the compositeRoleRefs attribute has been very beneficial for us, as it allows using the same manifest across different environments where the UUIDs differ and they can be originally unknown. However, starting from v2, the resolver function also modifies the original manifest when the compositeRoleRefs attribute is specified.

Code Lines:

https://github.com/crossplane-contrib/provider-keycloak/blob/main/apis/cluster/role/v1alpha1/zz_generated.resolvers.go#L49

https://github.com/crossplane/crossplane-runtime/blob/main/pkg/reference/reference.go#L408

Although the Crossplane runtime's ResolveMultiple reference function sorts references by ID, could you add a mechanism to disable this at the Keycloak provider level? I guess this feature is useful for many Crossplane providers, but for Keycloak, from my point of view , it’s more of a drawback — role IDs are randomly generated by the Keycloak database, while names and labels are more meaningful and likely to be provided through Crossplane.

I have just tested the Role.role.keycloak.crossplane.io object, but I'm afraid that others which use references might be affected as well.

[Breee]

Show me your argocd App as well please

[yoelpadronglez]

Currently we are using this simple argocd app configuration

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: exp-springboot-app
  namespace: exp
spec:
  destination:
    name: exp-cluster
    namespace: exp
  project: devops
  source:
    helm:
      releaseName: springboot-app
      valueFiles:
        - exp-values.yaml
    path: delivery
    repoURL: my-repo
    targetRevision: main

[Breee]

Please confirm for me, that this is not a Helm issue. I can Look into it tomorrow maybe more deep

…

On Tue, Dec 16, 2025, 15:54 yoelpadronglez ***@***.***> wrote: *yoelpadronglez* left a comment (crossplane-contrib/provider-keycloak#462) <#462 (comment)> Currently we are using this simple argocd app configuration apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: exp-springboot-app namespace: exp spec: destination: name: exp-cluster namespace: exp project: devops source: helm: releaseName: springboot-app valueFiles: - exp-values.yaml path: delivery repoURL: my-repo targetRevision: main — Reply to this email directly, view it on GitHub <#462 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3JPMJK3HPJRHDAROW7Q6L4CAMITAVCNFSM6AAAAACPGJDMASVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMNRQHE2TQNRRHA> . You are receiving this because you commented.Message ID: ***@***.***>

[yoelpadronglez]

No, really — you can actually run the test without using either Helm or ArgoCD.
Try creating these two client roles and then assign them as composite roles to the role previously specified (admin). You’ll notice that, depending on the order of the client roles, the compositeRolesRefs list might change — setting either “read” or “write” first, depending on your environment and the UIDD generated for these clients.

apiVersion: role.keycloak.crossplane.io/v1alpha1
kind: Role
metadata:
  name: read
spec:
  forProvider:
    clientIdSelector:
      matchLabels:
        upbound.io/name: springboot-app
    name: read
    realmId: my-realm
  managementPolicies:
    - '*'
---
apiVersion: role.keycloak.crossplane.io/v1alpha1
kind: Role
metadata:
  name: write
spec:
  deletionPolicy: Delete
  forProvider:
    clientIdSelector:
      matchLabels:
        upbound.io/name: springboot-app
    name: write
    realmId: my-realm
  managementPolicies:
    - '*'

The easiest way to check the difference between the cluster and your local template is to run kubectl diff -f template.yaml

[haarchri]

Xref: crossplane/crossplane#6919

[Breee]

I see, let's wait then until the crossplane devs speak.

As a workaround you could proably use compositeRolesSelector and match based on labels or you ignore the diffs in argocd.

I'm not sure yet if we can (and want) to override this logic in the provider config by writing a modifier (similar to https://github.com/crossplane-contrib/provider-keycloak/blob/main/config/multitypes/modifier.go)

[yoelpadronglez]

Hi,

Unfortunately, the workaround you proposed doesn't work in all my scenarios. I'm using some realm roles that can point to multiple composite roles more associated with application permissions. With CompositeRolesSelector, all these composite roles must have the same labels (key:value), which breaks the decoupling between application-specific permissions and broader realm roles. Additionally, because CompositeRolesSelector restricts each key to a single value, it cannot achieve the same level of configurability as compositeRolesRefs.

For now, I can only set the CompositeRoles list in the manifest in order to keep my ArgoCD app in sync, but I would have to define the specific list of IDs in all environments, which would break the flexibility I currently have with Crossplane v1.

Regarding your second proposal, I'm not completely sure I understand the final purpose you have in mind. In your example, I saw that you added an extra parameter to the Execution object in order to retrieve the IDs of the subflows, which are later provided via parent_flow_alias in the Terraform client, in the same way as flow IDs. The role Terraform object just has the compositeRole ID list, so I'm not sure how it might solve the sorting issue with compositeRolesRefs list on the Kubernetes-Crossplane side.

[Breee]

As crossplane/crossplane#6919 is now closed, i bumped to crossplane runtime 2.2.0 but now upjet is broken and i need to wait for:

crossplane/upjet#602