samlp addon configuration is not valid about terraform-provider-auth0

[alexkappa]

Hi @alkar, thanks for reporting this. Unfortunately, Auth0 doesn't document the addon's very well and it's a trial and error process on our part. It should be a straightforward fix I hope, so I might be able to patch this soon. Meanwhile, if you're feeling adventurous please feel free to give it a go :)

[alexkappa]

@alkar I think it's a good way to go to define arbitrary JSON as it leaves the flexibility up to users. Given the state of addons in the Auth0 API, it's hard for us to maintain this cause of the lack of documentation (btw I've contacted their support team about it).

But it will pose a problem with users who already make use of addons defined the current way as this would be a backward incompatible change.

Please give me some time to look into your current progress and see how it all ties in.

[alkar]

I'll have a go at it, seems like an easy change. Wondering if you'd rather go with something like https://github.com/iancoleman/strcase or would rather have a solution based on the standard library?

[alkar]

@alexkappa I've made some progress in converting the keys to what is expected by the sampl plugin.

I wanted to add a couple more changes that address default and empty values: since sampl has its own set of defaults, I think it would be better (as in, safer and easier to maintain) to rely on the upstream defaults. Removing the schema defaults means that the attributes will be initialised with empty values which would then have to be caught programmatically. I felt this was a rather brittle approach and I backtracked a bit; what if we instead dropped support for individual attributes completely and instead allowed the user to supply their own JSON configuration string?

For example,

resource "auth0_client" "saml" {
  name        = "saml-example"
  app_type    = "regular_web"
  callbacks   = ["https://example.com/saml"]

  addons {
    samlp = <<EOF
{ my_config_here }
EOF
  }
}

I personally feel this approach is much more flexible and reduces the maintenance overhead (and shouldn't be strange to users, eg. IAM policies are more often than not managed this way).

Perhaps in the future, if there's more concrete documentation on samlp (and other addons) we could introduce datasources to handle config in HCL, again, similar to how aws_iam_policy_document works.

Thoughts?

[alkar]

@alexkappa Much agreed! I've not progressed any further on that branch, happy to work on a PoC and share.

I would argue that given the provider is still on 0.1.x there shouldn't be much relying on API compatibility between versions (I know I don't). Also, the current implementation produces invalid config so even if users do use it, it's going to be an actual fix and worth breaking the API for. But that's all up to you to decide how to handle :)

[kevinohara80]

Hey, any progress here? Just discovered this the hard way.

[github-actions]

This issue is stale because it has been open 30 days with no activity.
Stale issues will be closed after 5 days if no action is taken. If you
think this issue should not be closed, remove the stale label.