KEYCLOAK-13582 user federation provider and mapper

[chlunde]

JIRA ID

https://issues.redhat.com/browse/KEYCLOAK-13582

Additional Information

Support for LDAP and customizing it using mappers.

This PR builds on other PRs, only the latest commit is relevant. I will rebase when the other commits are merged.

Verification Steps

The configuration has been e2e tested using an export (this ensures all field names are correct).

For a manual test:

1. Create a realm CRD point to an existing LDAP

apiVersion: keycloak.org/v1alpha1
kind: KeycloakRealm
metadata:
  labels:
    app: sso
  name: ldap-realm
spec:
  instanceSelector:
    matchLabels:
      app: sso
  realm:
    displayName: LDAPRealm
    enabled: true
    id: ldap-realm
    realm: ldap-realm
    userFederationProviders:
      - displayName: "ldap"
        providerName: "ldap"
        config:
          vendor: "ad"
          connectionUrl: "ldap://localhost"
          bindDn: "USERNAME"
          bindCredential: "PASSWORD"
          usersDn: DC=example,DC=com"
          usernameLDAPAttribute: "mail"
          uuidLDAPAttribute: "objectGUID"
          searchScope: "2" # sub
          useTruststoreSpi: "ldapsOnly"
          trustEmail: "true"
          userObjectClasses: "person, organizationalPerson, user"
          rdnLDAPAttribute: "cn"
          editMode: "READ_ONLY"
          # debug: "false"
    userFederationMappers:
      - name: username
        federationProviderDisplayName: ldap
        federationMapperType: user-attribute-ldap-mapper
        config:
          always.read.value.from.ldap: 'true'
          is.binary.attribute: 'false'
          is.mandatory.in.ldap: 'true'
          ldap.attribute: mail
          read.only: 'true'
          user.model.attribute: username
      - name: MSAD account controls
        federationProviderDisplayName: ldap
        federationMapperType:  msad-user-account-control-mapper
        config:
          ldap.password.policy.hints.enabled: 'false'
      - name: last name
        federationProviderDisplayName: ldap
        federationMapperType: user-attribute-ldap-mapper
        config:
          always.read.value.from.ldap: 'true'
          is.binary.attribute: 'false'
          is.mandatory.in.ldap: 'true'
          ldap.attribute: sn
          read.only: 'true'
          user.model.attribute: lastName
      - name: email
        federationProviderDisplayName: ldap
        federationMapperType: user-attribute-ldap-mapper
        config:
          always.read.value.from.ldap: 'true'
          is.binary.attribute: 'false'
          is.mandatory.in.ldap: 'true'
          ldap.attribute: mail
          read.only: 'true'
          user.model.attribute: email
      - name: full name
        federationProviderDisplayName: ldap
        federationMapperType: full-name-ldap-mapper
        config:
          ldap.full.name.attribute: cn
          read.only: 'true'
          write.only: 'false'

2. Log in using usernamer and password

Checklist:

• Automated Tests
• Documentation changes if necessary
• (If required) Discussed on Keycloak DEV

[kfox1111]

This looks really good. But bind credential should probably be a secret ref.

[chlunde]

But bind credential should probably be a secret ref.

@kfox1111 Yes, I think so too, but there should be a unified way to do it. The samme problem already exists for example in clientSecret for an IdP. I briefly asked about it here:

• https://issues.redhat.com/browse/KEYCLOAK-12677?focusedCommentId=14238775&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14238775
• Best practices: Consider adding a section about secrets in CRs operator-framework/community-operators#1981

But I think it should be done in another PR. I never got a response in KEYCLOAK-12677 - do you think we should create a new Jira issue for this (clientSecret, bindCredential etc) and discuss possible designs there?

[slaskawi]

But I think it should be done in another PR. I never got a response in KEYCLOAK-12677 - do you think we should create a new Jira issue for this (clientSecret, bindCredential etc) and discuss possible designs there?

@chlunde Yes, that's a good point. All Secret refs should be somehow consistent across all our CRs. Could you please spin up a discussion on Keycloak DEV: https://groups.google.com/g/keycloak-dev ?

[slaskawi]

@chlunde I like the proposed change but the situation is exactly the same as in #230 (review)

[slaskawi]

@chlunde Since your previous PR has been merged, maybe we can get this one rolling?

[chlunde]

@slaskawi done

[slaskawi]

Integrated, thanks @chlunde !

[Chive]

@slaskawi / @chlunde sorry to hijack this issue, I was unsure on where to best post this.
Is there any plan on implementing the mappers (identityProviderMappers) for the already existing identity providers (added in #49)?

[slaskawi]

@Chive We have a ticket for this - https://issues.redhat.com/browse/KEYCLOAK-13098. I think it's best to subscribe to it.

Perhaps you'd be interested in contributing this feature?