Giter VIP home page Giter VIP logo

Comments (4)

tomrutsaert avatar tomrutsaert commented on August 28, 2024

The solution might be in writing a custom Marshal and Unmarshal method, where additional config will come from an extra_config field in the idp resource

func (f *IdentityProviderConfig) UnmarshalJSON(data []byte) error {
	f.ExtraConfig = map[string]interface{}{}
	err := json.Unmarshal(data, &f.ExtraConfig)
	if err != nil {
		return err
	}
	knownkey, ok := f.ExtraConfig["knownkey"].(string)
	if !ok {
		return errors.New("knownkey must exist and be a string")
	}
	f.KnownKey = knownkey
	delete(f.ExtraConfig, "knownkey")
	return nil
}

func (f *IdentityProviderConfig) MarshalJSON() ([]byte, error) {
	out := map[string]interface{}{}
	for k, v := range f.ExtraConfig {
		out[k] = v
	}
	out["knownkey"] = f.Knownkey
	return json.Marshal(out)
}

something like this

from terraform-provider-keycloak.

mrparkers avatar mrparkers commented on August 28, 2024

I like the idea of the extra_config field, although I don't actually use identity providers in Keycloak so I am not sure how valuable my opinion is.

@AndrewChubatiuk implemented most (if not all) of this, so I'd defer to his opinion or anyone else who actually uses this. Any thoughts here?

from terraform-provider-keycloak.

AndrewChubatiuk avatar AndrewChubatiuk commented on August 28, 2024

@mrparkers @tomrutsaert
I like idea of having one keycloak_identity_provider resource for all types of providers with validation schemas for config attribute map for all identity provider types except custom. And in this case IdentityProviderConfig struct can be replaced with map[string]interface

from terraform-provider-keycloak.

tomrutsaert avatar tomrutsaert commented on August 28, 2024

Keep in mind, that most custom implementations will build upon or extend an existing identity provider type, and thus also want the those existing identity provider attributes with validation.
Therefor I went with the extra_config within config. I have implemented everything in identity_provider built only extended the resource_keyclaok_oidc_identity_provider
It should be minimal effort to do the same for resource_keycloak_saml_identity_provider.
(I did not do the saml part, because making a working test would take time)
@mrparkers and @AndrewChubatiuk Please take a look at PR: #137

from terraform-provider-keycloak.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.