Support protocol mappers about terraform-provider-keycloak HOT 3 CLOSED

Thoughts on this:

1. It looks like this resource could be shared between clients and client-scopes. Meaning, you could add a protocol mapper to a client so only that client uses this mapper, or you could add it to a scope so that any client using that scope will have this mapper. This means that the resource would need to use attributes such as client_id or client_scope_id in order to tie it to one or the other. It would probably be required to set one and only one of these attributes.
2. There are some protocol mappers that can be used for both openid and saml clients/client-scopes (such as User Attribute), but the APIs are so drastically different between the two that it would probably make sense to split them out according to the protocol. This would mean that the protocol would be part of the name of the resource as opposed to an attribute on the resource.

With this in mind, perhaps the resource may look something like this?

resource "keycloak_openid_hardcoded_claim_protocol_mapper" "my-foo-claim" {
     client_id = "${keycloak_client.test-client.id}"
     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 
}

from terraform-provider-keycloak.

1. Not that familiar with client scopes, but allowing for client and client scopes to share the resource seems like a good idea.
2. If the APIs are that different between openid connect and saml, then I agree that it makes sense to split them out. I don't imagine there's a use case for changing one protocol to the other.

The config you posted looks good to me. I forgot to prefix the resource with keycloak and tie the resource to an actual client in my example.

from terraform-provider-keycloak.

I'm going to take a shot at implementing this.

from terraform-provider-keycloak.