mrparkers / terraform-provider-keycloak

Terraform provider for Keycloak

terraform-provider-keycloak

Terraform provider for Keycloak.

Docs

All documentation for this provider can now be found on the Terraform Registry: https://registry.terraform.io/providers/mrparkers/keycloak/latest/docs

Installation

This provider can be installed automatically using Terraform >=0.13 by using the terraform configuration block:

terraform {
  required_providers {
    keycloak = {
      source = "mrparkers/keycloak"
      version = ">= 4.0.0"
    }
  }
}

If you are using Terraform 0.12, you can use this provider by downloading it and placing it within one of the implied local mirror directories. Or, follow the old instructions for installing third-party plugins.

If you are using any provider version below v2.0.0, you can also follow the old instructions for installing third-party plugins.

A note for users of the legacy Wildfly distribution

Recently, Keycloak has been updated to use Quarkus over the legacy Wildfly distribution. The only significant change here that affects this Terraform provider is the removal of /auth from the default context path for the Keycloak API.

If you are using the legacy Wildfly distribution of Keycloak, you will need to set the base_path provider argument to /auth. This can also be done by using the KEYCLOAK_BASE_PATH environment variable.

Supported Versions

This provider will officially support the latest three major versions of Keycloak, although older versions may still work.

The following versions are used when running acceptance tests in CI:

• 21.0.1 (latest)
• 20.0.5
• 19.0.2

Releases

This provider uses GoReleaser to build and publish releases. Each release published to GitHub contains binary files for Linux, macOS (darwin), and Windows, as configured within the .goreleaser.yml file.

Each release also contains a terraform-provider-keycloak_${RELEASE_VERSION}_SHA256SUMS file, accompanied by a signature created by a PGP key with the fingerprint C508 6791 5E11 6CD2. This key can be found on my Keybase account at https://keybase.io/mrparkers.

You can find the list of releases here. You can find the changelog for each version here.

Note: Prior to v2.0.0, a statically linked build for use within Alpine linux was included with each release. This is no longer done due to GoReleaser not supporting CGO. Instead of using a statically linked, build you can use the linux_amd64 build as long as libc6-compat is installed.

Development

This project requires Go 1.19 and Terraform 1.4.1. This project uses Go Modules for dependency management, which allows this project to exist outside of an existing GOPATH.

After cloning the repository, you can build the project by running make build.

Local Environment

You can spin up a local developer environment via Docker Compose by running make local. This will spin up a few containers for Keycloak, PostgreSQL, and OpenLDAP, which can be used for testing the provider. This environment and its setup via make local is not intended for production use.

Note: The setup scripts require the jq command line utility.

Tests

Every resource supported by this provider will have a reasonable amount of acceptance test coverage.

You can run acceptance tests against a Keycloak instance by running make testacc. You will need to supply some environment variables in order to set up the provider during tests. Here is an example for running tests against a local environment that was created via make local:

KEYCLOAK_CLIENT_ID=terraform \
KEYCLOAK_CLIENT_SECRET=884e0f95-0f42-4a63-9b1f-94274655669e \
KEYCLOAK_CLIENT_TIMEOUT=5 \
KEYCLOAK_REALM=master \
KEYCLOAK_URL="http://localhost:8080" \
make testacc

License

MIT

terraform-provider-keycloak's Issues

missing docs for resources / data sources

This is a reminder for me to add missing docs for the following resources and data sources:

resources:

• keycloak_openid_client_authorization_resource
• keycloak_openid_client_authorization_scope
• keycloak_openid_client_authorization_permission
• keycloak_openid_client_service_account_role
• keycloak_oidc_identity_provider
• keycloak_user_template_importer_identity_provider_mapper
• keycloak_attribute_to_role_identity_provider_mapper
• keycloak_hardcoded_role_identity_provider_mapper
• keycloak_hardcoded_attribute_identity_provider_mapper

data sources:

• keycloak_openid_client_authorization_policy

I will try to add these when I have time, and I will happily accept PRs from anyone who is interested in contributing these.

assign client scopes to a client

Tagged as "new resource" because I think a separate resource is the best way to do this.

Authoritative:

resource "keycloak_openid_client" "test_client" {
  client_id           = "test-client"
  name                = "test-client"
  realm_id            = "master"
  description         = "a test client"

  access_type         = "CONFIDENTIAL"
  valid_redirect_uris = [
    "http://localhost:8080/callback"
  ]
}

resource "keycloak_openid_client_scope" "test_client_scope" {
  name                = "foo1"
  realm_id            = "master"

  description         = "test"
  consent_screen_text = "hello"
}

resource "keycloak_openid_client_default_client_scopes" "authoritative_scopes" {
    realm_id       = "master"
    client_id      = "${keycloak_openid_client.test_client.id}"
    default_scopes = [
        "profile",
        "email",
        "${keycloak_openid_client_scope.test_client_scope.name}"
    ]
}

Non authoritative:

resource "keycloak_openid_client" "test_client" {
  client_id           = "test-client"
  name                = "test-client"
  realm_id            = "master"
  description         = "a test client"

  access_type         = "CONFIDENTIAL"
  valid_redirect_uris = [
    "http://localhost:8080/callback"
  ]
}

resource "keycloak_openid_client_scope" "test_client_scope" {
  name                = "foo1"
  realm_id            = "master"

  description         = "test"
  consent_screen_text = "hello"
}

resource "keycloak_openid_client_default_client_scope" "non_authoritative_scopes" {
    realm_id      = "master"
    client_id     = "${keycloak_openid_client.test_client.id}"
    default_scope = "${keycloak_openid_client_scope.test_client_scope.name}"
}

thoughts:

1. it should be okay to reference scopes by their name since those are supposed to be unique across the realm. my only issue with this is all of the other resources reference other resources by id, but doing this would make it hard to reference pre-existing scopes like "profile"
2. I'm borrowing the concept of authoritative vs non-authoritative resources from the Google provider which applies this concept very well. There needs to be big warnings to inform users that you shouldn't use these resources together on the same client.
3. as mentioned in #14, I'm trying to separate openid and saml versions of the same resource (such as client) because the APIs are so different. however it might not be needed in this case.
4. optional scopes will have a different resource than the example above but will work the same

Update go module terraform from terraform v0.12.0-rc1 to terraform v0.12.0

Currently the realease candidate (rc1) of the module terraform is referenced at go.mod
=> upgrade to release version

Provider should support data sources

In order to read Keycloak generated credentials, provider should support data source on client and user.

Add ability to disable direct access grants for a client

This would entail adding direct_access_grants_enabled to keycloak_openid_client. Most applications should go through the standard flow and should not be able to use the resource owner credentials flow.

ldap user attribute mapper: don't assume all fields will be returned by Keycloak API

this line can fail if the ldap user federation provider has cache disabled, because the Keycloak API won't return this field

401 Unauthorized error

@mrparkers Thank you for providing terraform provider for keycloak.
I would like to use this plugin for my keycloak.
but when I tried to use it, I have 401 Unauthorized error.

I was assuming that my keycloak configuration was wrong. ( I gave admin role to the keycloak client )
but when I tested with keycloak plugin provided from https://github.com/tazjin/terraform-provider-keycloak, it's working properly.

it seems like that tazjin's repo is no longer maintained, I would like to try your plugin.

can you please check if you can give me advise...

** version information **
terraform : v0.11.11
terraform provider keycloak : v1.4.0
keycloak version : 4.7.0

** my test code **

provider "keycloak" {
    client_id         = "terraform"
    client_secret  = "xxxxxxx"
    url                 = "https://xxxx.com"
}

resource "keycloak_realm" "iot_sso" {
    realm   = "iot-sso"
}

** terraform apply error **

* keycloak_realm.iot_sso: error sending GET request to /auth/admin/serverinfo: 401 Unauthorized

** terraform import error **

$  ~/terraform1111 import keycloak_realm.iot_sso iot-sso
keycloak_realm.iot_sso: Importing from ID "iot-sso"...
keycloak_realm.iot_sso: Import complete!
  Imported keycloak_realm (ID: iot-sso)
keycloak_realm.iot_sso: Refreshing state... (ID: iot-sso)

Error: keycloak_realm.iot_sso (import id: iot-sso): 1 error(s) occurred:

* import keycloak_realm.iot_sso result: iot-sso: keycloak_realm.iot_sso: error sending GET request to /auth/admin/realms/iot-sso: 401 Unauthorized

Romi

Upload provider plugin releases to open domain to allow unauthenticated downloads

It is not possible to download the releases as a machine user without github credentials. Would it be possible to also upload the artifacts to an official S3 bucket where the plugin can be downloaded freely without credentials. This is necessary for building docker images in our CI/CD system that require unauthenticated access to these artifacts.

backfill test for authenticating against non-master realm

Some acceptance tests are needed for authenticating against a non-master realm, which was added in #88.

allow for mapping roles to users and service accounts

Discussion started in #143.

For mapping roles to a service account, it makes sense to make to have a data source to get the ID of that service account, and use a resource like keycloak_user_roles to map roles to it. It might look something like this:

resource "keycloak_openid_client" "client" {
  realm_id  = "${keycloak_realm.realm.id}"
  client_id = "client"
  name      = "client"

  enabled = true

  access_type   = "CONFIDENTIAL"
  client_secret = "secret"
  
  service_accounts_enabled = true
}

data "keycloak_service_account_user" "client_service_account" {
  client_id = "${keycloak_openid_client.client.id}"
}

resource "keycloak_role" "role" {
  realm_id = "${keycloak_realm.realm.id}"
  name     = "my-role"
}

resource "keycloak_user_roles" "client_service_account_roles" {
  realm_id = "${keycloak_realm.realm.id}"
  user_id  = "${data.keycloak_service_account_user.client_service_account.id}"

  roles = [
    "${keycloak_role.role.id}"
  ]
}

thoughts? cc @rlewan @camelpunch

ldap protocol mappers: missing import validation

Just got burned by a lack of import validation for any ldap protocol mapper. It should check to ensure you're providing the realm, ldap federation ID, and mapper ID, and tests should be added around this as well.

Support hardcoded-ldap-group-mapper LDAP Mapper

This would grant a specified Keycloak group to each Keycloak user linked with LDAP.
See documentation

It could look like this:

resource "keycloak_ldap_hardcoded_group_mapper" "group_mapper" {
  realm_id                 = "${keycloak_realm.my-realm.id}"
  ldap_user_federation_id  = "${keycloak_ldap_user_federation.my-ldap.id}"
  name                     = "my-group-mapper"
  group                    = "my-group"
}

Support for identity providers

It would be good to provide a resource for managing Identity Providers.

https://www.keycloak.org/docs-api/5.0/rest-api/index.html#_identity_providers_resource

keycloak_group_memberships: 404 response not handled

If a group that has its members controlled by keycloak_group_memberships is manually deleted, subsequent plans or applies will fail. It should automatically be removed from state if the group no longer exists.

Support protocol mappers

REST API docs

Admin UI:

There are a number of these so there would probably resources for each rather than a shared mega-resource.

Example Terraform config for adding a hard-coded claim:

resource "hard_coded_claim" "my-foo-claim" {
     protocol = "openid-connect"
     name = "foo-claim"
     claim_name = "foo"
     claim_string_value = "bar" // mutually exclusive long_value, int_value, bool_value fields
     add_to_access_token = true
     add_to_id_token = false 
}

bind_credential cannot be updated after being created

Since the diff has to be ignored after initial creation, there is a bug if you go to update the bind_credential after the resource is initially provisioned.

Refactor KeycloakClient to use oauth2 and clientcredentials libraries

Much of the functionality in KeycloakClient for logging in and refreshing the access token seems to re-implement behavior already implemented in golang.org/x/oauth2 and golang.org/x/oauth2/clientcredentials. This issue includes research into whether those libraries would be sufficient, and refactoring KeycloakClient to use them if they are. I would be happy to take this on.

Plugin doesn't work inside official terraform image (alpine)

When trying to run terraform with the keycloak-provider configured inside a docker container, the executable cannot be run.

It appears the released binary of the keycloak-provider is links to the glibc. However, the official terraform image is based on Alpine Linux and therefore uses musclibc.

We made it work that way with previous releases so I'm confident it's only a matter of rebuilding the latest version.

The complete behaviour within the container is :

> /provision # terraform init

Initializing the backend...

Initializing provider plugins...

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
> /provision # terraform plan

Error: Failed to instantiate provider "keycloak" to obtain schema: fork/exec /root/.terraform.d/plugins/terraform-provider-keycloak_v1.8.0: no such file or directory

> /provision # ls -al /root/.terraform.d/plugins/terraform-provider-keycloak_v1.8.0 
-rwxr-xr-x    1 root     root      27065137 Jun 12 09:03 /root/.terraform.d/plugins/terraform-provider-keycloak_v1.8.0
> /provision # ldd /root/.terraform.d/plugins/terraform-provider-keycloak_v1.8.0
	/lib64/ld-linux-x86-64.so.2 (0x7fb0bab6a000)
	libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7fb0bab6a000)
	libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fb0bab6a000)

> /provision # /root/.terraform.d/plugins/terraform-provider-keycloak_v1.8.0
/bin/sh: /root/.terraform.d/plugins/terraform-provider-keycloak_v1.8.0: not found

> /provision # ldd /root/.terraform.d/plugins/terraform-provider-keycloak_v1.1.0
ldd: terraform-provider-keycloak_v1.1.0: Not a valid dynamic program

I'm not familiar enough with Go builds so I am unable to provide a fix for this :( but it used to work (last tested with version 1.1.0).

Hi from the other terraform-provider-keycloak

Hi there,

whilst looking through the list of community terraform providers, I got surprised a provider for Keycloak was listed. I though the one I've been contributing to and using at work the last couple of years, was the only one around -- obviously not, hoooray! 😄

Have you seen tazjin/terraform-provider-keycloak before? It was initially created by a consultant we hired at work, who's moved on to other projects, but we're still actively using it and expanding it as needed..

Your project looks great! At first glance it looks like you've mapped quite a few more resources than we have, and an actual presence of tests which we have neglected for too long.

Is this provider being actively used in production environments and has proven to be stable? Would you mind if we as maintainers of the other provider, started contributing to this project?

Support hardcoded-ldap-role-mapper LDAP Mapper

This would grant a specified Keycloak role to each Keycloak user linked with LDAP.
See documentation

It could look like this:

resource "keycloak_ldap_hardcoded_role_mapper" "role_mapper" {
  realm_id                = "${keycloak_realm.my-realm.id}"
  ldap_user_federation_id = "${keycloak_ldap_user_federation.my-ldap.id}"
  name                    = "my-role-mapper"
  role                    = "my-role"
}

Custom Identity Provider with extra custom config

We have a custom oidc identity provider with custom config.
I would like to add this extra config to this terraform keycloak provider.
I do not how to go forward with this.

Do I change the IdentityProvider implementation to change IdentityProviderConfig struct to be just a map[string]interface{} where i do a mapping per field so that the have the correct json key?
for example:

func getOidcIdentityProviderFromData(data *schema.ResourceData) (*keycloak.IdentityProvider, error) {
	rec, _ := getIdentityProviderFromData(data)
	rec.ProviderId = "oidc"

	config := make(map[string]interface{})
	if v, ok := data.GetOk("config"); ok {
		for key, value := range v.(map[string]interface{}) {
			if key == "backchannel_supported" {
				config["backchannelSupported"] = keycloak.KeycloakBoolQuoted(value.(bool))
			}else if key == "jwks_url" {
				config["useJwksUrl"] = keycloak.KeycloakBoolQuoted(true)
				config["jwksUrl"] = value.(string)

			}else if ....	{
	                      .....
			}else{
				config[key] = value.(string)  // all extra config
			}
		}
	}
	rec.Config = config

Or do I create a CustomIdentityProvider struct which has the same methods as IdentityProvider, but where all config parameters are part of a map[string]interface{}
I still would have to map every field like in the solution above.

Or do you have another suggestion?

keycloak_realm: token lifespan settings all default to 0

I forgot to use omitempty for the POST body for those properties 🤦‍♂️

Errors aren't checked properly when removing a group membership user from a group

terraform-provider-keycloak/provider/resource_keycloak_group_memberships.go

Line 106 in 0f1fe1b

return nil

I think this code should be returning err rather than nil. As-is, if there's an error removing a user from a group nothing will happen.

Support Service Account Roles for OIDC clients

In order to configure the roles available to the service account retrieved on behalf of this client...
See documentation.

service_accounts_enabled has to be enabled:

resource "keycloak_openid_client" "my-client" {
  realm_id                     = "${keycloak_realm.my-realm.id}"
  client_id                    = "my-client"
  service_accounts_enabled     = true
  ...
}

data source for realm keys

Provide a data source for retrieving keys of a realm.
The REAST API of Keycloak provides a GET method for realm keys
Filtering by algorithm and other attributes would be useful.

keycloak_realm: incorrect default for reset_credentials_flow attribute

terraform-provider-keycloak/provider/resource_keycloak_realm.go

Line 342 in 6582455

Default: "registration",

should be "reset credentials"

provider should support using other realms for authentication

Currently, this provider assumes you will be using the master realm for authentication and configuring Keycloak, but I think it makes sense to want to use other realms for this too, perhaps to limit the scope of a service account to only one realm, or to allow different teams to configure their own realms without being given access to master.

In particular, I think the provider would have to support:

• Specifying the realm in config
• Specifying the realm via environment variable (which takes precedence if both are specified?)
• If the realm is specified either way, imports should not require a realm ID
• If the realm is specified either way, realm_id should not be a required attribute on all resources

Create an initial password when creating a user

This is less a feature request than a mergeability poll, as I'm very much inclined to submit a pull request for this.

My feature would be

• When a user is created and initial_password is set
  A call to /users/{user_id}reset-password is made to initialize a password.

• When a user is updated and initial_password is set
  No further call is made

• When initial_password is not set, do as is done now.

Would you accept such a feature ?

Add ability to disable text on consent screen for client scopes

There's currently a consent_screen_text field on the client scope resource, but no way to disable text entirely (this is configurable on a client basis as well).

For the API, it looks like this requires setting attributes.display.on.consent.screen.

keycloak_realm: occasionally gets a 500 when attempting to delete

this seems to only happen during acceptance tests (where lots of realms are being created and destroyed), but it's still annoying enough to document it here. a temporary fix was added in #29

Custom cache periods for user federation

Currently it's only possible to use the DEFAULT or NO_CACHE cache policies with the provider; all the other cache policies require some user input (e.g., EVICT_DAILY needs to know the hour and minute to evict).

avoid using http verbs in function names within the provider package

example that should be fixed: https://github.com/mrparkers/terraform-provider-keycloak/blob/master/provider/keycloak_realm.go#L172

I prefer terms like map over get since get can mean many different things within the context of a provider interacting with a restful API

support SAML Group list Mapper

in order to map user's group list in a SAML client, a new saml group membership similar to the oidc one is needed

protocol mapper token setting attributes are inconsistent

I think I prefer add_to_id_token over id_token_claim, as an example.

add validation to enforce unique names for protocol mappers

for some reason, two different protocol mappers can't have the same name. example tf config that fails with a 409 conflict:

resource "keycloak_realm" "test" {
  realm                = "test"
  enabled              = true
  display_name         = "foo"

  account_theme        = "base"

  access_code_lifespan = "30m"
}

resource "keycloak_openid_client_scope" "test_client_scope" {
  name                = "foo1"
  realm_id            = "${keycloak_realm.test.id}"

  description         = "test"
  consent_screen_text = "hello"
}

// one of the two resources below will succeed, one will fail

resource "keycloak_openid_group_membership_protocol_mapper" "map_group_memberships_client_scope" {
  name            = "foo"
  realm_id        = "${keycloak_realm.test.id}"
  client_scope_id = "${keycloak_openid_client_scope.test_client_scope.id}"
  claim_name      = "bar2"
}

resource "keycloak_openid_user_attribute_protocol_mapper" "map_user_attributes_client_scope" {
  name            = "foo"
  realm_id        = "${keycloak_realm.test.id}"
  client_scope_id = "${keycloak_openid_client_scope.test_client_scope.id}"
  user_attribute  = "foo2"
  claim_name      = "bar2"
}

validation should be added to ensure that you can't create a protocol mapper with the same name as another one, and give a good error message instead of "409 conflict"

Add the ability to create roles and client-roles

Hi, thank you for this provider!
We have a realm installation that features quite a lot of different roles and client-roles, and we would love to be able to create them through Terraform.

Is this new resource something you were considering adding?

Add support for default groups

AFAICT, there is no way to specify default groups at the moment. This would be fairly easy to implement, since it's a really basic resource. The relevant endpoints are:

GET /{realm}/default-groups (returns a list of all default groups)
PUT /{realm}/default-groups/{groupId} (add a group to the list of default groups)
DELETE /{realm}/default-groups/{groupId} (delete a group from the list of default groups)

The first way that comes to mind for how this could be implemented is having a very basic resource for each default group that simply maps a realm id to a group id. This maps very well to the keycloak API. The HCL would look something look this:

resource "keycloak_group" "example_group" {
  realm_id = "${keycloak_realm.realm.id}"
  name     = "example-group"
}

resource "keycloak_default_group" "example_group" {
  realm_id = "${keycloak_realm.realm.id}"
  group_id = "${keycloak_group.example_group.id}"
}

We could also have a default groups property on realms, or have a default groups resource, or have a default group property on groups, but I don't think those solutions map very well to the API. Additionally, we could specify it on the realm, but then we get into a scenario where if a realm references groups that need to be created after the realm is then there's a potential deadlock.

I would be happy to take a crack at adding this feature.

user_info => userinfo

this definitely seems like it should be one word: https://openid.net/specs/openid-connect-core-1_0.html#UserInfo

there are several places in the code where this could be changed.

standardize indentation in tf config for acceptance tests

• tabs for indentation. example that needs to be fixed
• align properties on =. example that needs to be fixed

use the same import function for all protocol mappers

Support flows and executions

This would allow for Terraform to manage arbitrary execution flows that can then override the default flows on either a client or realm-level; the main benefit being that it would allow for custom authenticators to be used to paper over legacy auth solutions or even to require customers to accept new terms and conditions.

API docs:

• flows
• executions

// "basic-flow" is the authentication provider id
keycloak_authentication_basic_flow "custom-terms-flow" { 
      realm_id = "${keycloak_realm.my-realm.id}"
      alias =  "require-new-terms-and-conditions"
      description = "Make customers accept our new T&C"
}

keycloak_authentication_execution "custom-terms-execution" {
       flow_id = "${keycloak_authentication_basic_flow.custom-terms-flow.id}"

       provider = "terms-and-conditions-authenticator"
       config = "?" // this can be an arbitrary map, so maybe it deserves a custom resource
}

Merge with https://github.com/tazjin/terraform-provider-keycloak?

Hello
Thanks for the great work you did on Terraforming Keycloak!!!
It's too bad to have 2 providers covering different parts of Keycloak instead of one with better coverage...

Is there a reason why you didn't go with https://github.com/tazjin/terraform-provider-keycloak?
It seems to be existing since a moment now...

Cedric

Add ability to set a client role with composite_roles = an empty list

Hi,

I am using this version :

ii  terraform-provider-keycloak    1.10.0+git20190907.f15366f     amd64    Terraform keycloak provider

When I try to set an openid connect client role without any composite role (an empty list), I have got an error:

resource "keycloak_role" "role_yyyy" {
  realm_id        = "${module.realm_xxxx.id}"
  client_id       = "${module.openid_client_xxxx_yyyy.id}"
  name            = "user"
  composite_roles = []
}

Plan:

Error: keycloak_role.role_yyyy: composite_roles: attribute supports 1 item as a minimum, config has 0 declared

I would like to be able to set an empty list to be sure of the conformity of my role.

Thank you,

Pierre

validate methods should use KeycloakClient as receiver

some validate methods require some communication with the keycloak server, so I have been passing a pointer to the keycloak client in order to do this. instead of this, all validate methods should use the keycloak client as a receiver and take the struct that is being validated as an argument.

Support custom user federation with extra config parameters.

We have a custom user federation SPI that connects to our legacy my_users postgresql database.
In our Custom SPI we have some extra config parameters: jdbc_url, user, ...

We were hoping that we could pass along these extra config parameters through the keycloak_custom_user_federation terraform config.
But it seems that the "keycloak_custom_user_federation" only knows the fields that were defined in CustomUserFederation struct.

Is there a way to make our config work with current implementation?
If not, what would need to be changed, so that custom user federation with extra config parameters would work. Can we work with a config map variable?

I would prefer not to fork this project to extend CustomUserFederation struct with our specific case config fields. I rather create generic solution for all custom federation SPIs.

we would have following config

resource "keycloak_custom_user_federation" "my-user-fed" {
	name        	= "my-user-fed"
	realm_id    	= "${keycloak_realm.test.id}"
	enabled     	= true
	priority 		= "0"
	jdbc_url 		= "jdbc:postgresql://postgres:5432/my_users"
	user			= "myuser"
	password	= "mypassword"

	cache_policy 	= "DEFAULT"
}

or perhaps

resource "keycloak_custom_user_federation" "my-user-fed" {
	name        	= "my-user-fed"
	realm_id    	= "${keycloak_realm.test.id}"
	enabled     	= true
	priority 		= "0"
        extra_config  {
	       jdbc_url 		= "jdbc:postgresql://postgres:5432/my_users"
	       user			= "myuser"
	       password	        = "mypassword"
        }
	cache_policy 	= "DEFAULT"
}

Realm creation implies creation of clients and roles, results in conflict

For example, if you try to create a new realm at the same time as creating the account client and the account roles because you need to reference them when you create groups, you'll get a 409 conflict. I don't know a whole bunch about terraform, so this might just be something we have to deal with. Is there a way around this? Like where when a realm is created if clients/roles exist that were created they'll automatically be imported?

clients: support configuring of Scope

Currently the scope of a client (ATTENTION: do not do not confuse with Client Scopes / Scope Mapping) can not beconfigured. The default configuration uses Full Scope Allowed=TRUE. I want to be able to set this to Full Scope Allowed=FALSE.

The REST API requires to update the client with a clientrepresentation where fullScopeAllowed=false

missing import tests for protocol mapper resources

Add additional realm fields

It would be great to manage the email options for a realm; this is needed for "forgot password" emails and email verification.

Another missing field is offline_session_max_lifespan_enabled. It controls whether offline_session_max_lifespan is enforced:

if you enable the option Offline Session Max Limited, then the offline token expires after 60 days regardless of using the offline token for a refresh token action (this value, Offline Session Max lifespan, can also be changed in the administration console in the Tokens tab under Realm Settings)

support multiple keycloak versions + acceptance tests

#106 upgrades the provider to support Keycloak 6.0.1. While I don't believe the provider itself needs to be changed to support each version of Keycloak, it would be nice for the acceptance tests to test against all supported versions to give confidence to the users who are not ready to upgrade yet.