Unable to use `addons` when creating client. about terraform-provider-auth0

[jeff-french]

That's the approach I ended up going with. I've got a set of updates to both the underlying go-auth0 library as well as this provider. I'm still doing some testing on them but I will hopefully get some PRs up later today.

[alexkappa]

Hi @jeff-french thanks for submitting this. It seems the addons property is not properly defined in the terraform schema.

I'll try to work on this on the short term, but if you can give it a try yourself it would be a lot of help.

Cheers,
Alex

[alexkappa]

@jeff-french could you kick the tyres on #32 and let me know if we're on the right track?

[jeff-french]

@alexkappa Thanks for the quick response and PR! Unfortunately, it still didn't quite meet my use case. It appears that it works fine for setting first level primitive type properties of the addon but can't handle nested maps or lists.

Here's the full addons block I'm trying to use to configure the samlp addon:

addons                     = {
    samlp = {
      audience                       = "https://signin.aws.amazon.com/saml",
      mappings                       = {
        email = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
        name  = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
      },
      createUpnClaim                 = false,
      passthroughClaimsWithNoMapping = false,
      mapUnknownClaimsAsIs           = false,
      mapIdentities                  = false,
      nameIdentifierFormat           = "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent",
      nameIdentifierProbes           = [
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
      ]
    }
  }

When I try to run a plan I get this error when it hits a nested map:

Error: module.auth0_sso_tools.auth0_client.aws_sso: addons.0.samlp (mappings): '' expected type 'string', got unconvertible type '[]map[string]interface {}'

And this error when it hits a nested list:

Error: module.auth0_sso_tools.auth0_client.aws_sso: addons.0.samlp (nameIdentifierProbes): '' expected type 'string', got unconvertible type '[]interface {}'

If I remove the mappings and namedIdentifierProbes from my configuration the plan is successful but I can't create the resource because I need the full configuration.

I'm not sure the best way to solve this without having to maintain an extensive and exhaustive schema for every addon (that seems like a maintenance nightmare). The only other thing I could think of would be to support JSONifying a string for each addon. Something like this:

addons = {
  samlp = <<EOF
{
  "audience": "https://signin.aws.amazon.com/saml",
  "mappings": {
    "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
    "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
  },
  "createUpnClaim": false,
  "passthroughClaimsWithNoMapping": false,
  "mapUnknownClaimsAsIs": false,
  "mapIdentities": false,
  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent",
  "nameIdentifierProbes": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
  ]
}
EOF
}

And basically just take the entire string, parse it as JSON and send it on to the auth0 API as is. No idea how difficult that might be to implement.

[jeff-french]

I can't seem to find any authoritative source for the schema of all addons. After looking through UI I it may be that most or all addons only use first level primitive options (with the obvious exception of the samlp addon. So it may be enough to simply specify the full parameter schema for the samlp addon and the others will "just work" with the implementation in #32. I'll play this some more and if I get something working I'll put up a PR for it.

[alexkappa]

Hi @jeff-french, I'm torn as to which direction we should take on this. On one hand we could use json as you mention yourself, but I find it a little ugly to mix HCL and JSON and would prefer to avoid it if we can. On the other hand we either need to define all the properties of each addon which makes it pretty impractical in the long run. Perhaps defining the schema for samlp only which uses nested fields and leave the rest as is? Would you be willing to give this a go?

[jeff-french]

@alexkappa I've pushed up PRs at go-auth0/auth0#14 and #35. I don't have much experience writing Golang so I'm not sure where to go from here.

[alexkappa]

Closing this one as implemented in #35 and #58