The Auth0 Terraform Provider is the official plugin for managing Auth0 tenant configuration through the Terraform tool.
Home Page: https://registry.terraform.io/providers/auth0/auth0/latest/docs
License: Mozilla Public License 2.0
From terraform-provider-auth0 created by mwarkentin: alexkappa/terraform-provider-auth0#392
We have some users in auth0 which we've imported into terraform using this provider. There are some changes in user_metadata that are showing in the plan, but after applying, they show up again.
# auth0_user.money_admin_users["***+neb1@***.com"] will be updated in-place
~ resource "auth0_user" "money_admin_users" {
email = "***@***.com"
name = "***@***.com"
nickname = "***+neb1"
~ user_metadata = jsonencode(
~ {
- pw = "" -> null
- test-pw = "" -> null
Terraform 0.13.7
+ provider.auth0 v0.21.0
auth0_userresource "auth0_user" "admin_users" {
for_each = local.admin_users
connection_name = "Username-Password-Authentication"
email = each.key
roles = each.value.roles
password = random_password.money_admin_initial_passwords[each.key].result
user_metadata = jsonencode({
"user-management" : "Terraform"
})
lifecycle {
ignore_changes = [password, email_verified]
}
}After apply, the user_metadata should be in sync between terraform and auth0, resulting in a no-op on next plan.
There is always a change showing in the plan.
I'm opening this issue to capture several related issues opened on https://github.com/alexkappa/terraform-provider-auth0.
Under the hood, this Provider uses the Auth0 Go SDK to make calls to the Auth0 Management API.
It turns out that several struct fields makes use of the omitempty json tag. This means that any fields that are empty or nil will be omitted from the request that is sent to the Management API.
The Management API returns this error only for POST and PUT requests, but not for PATCH requests.
On PATCH certain values need to be empty depending on use case.
Currently it’s not possible to do this through the provider. It is only possible through the dashboard or calling the API manually.
From terraform-provider-auth0 created by Houndie: alexkappa/terraform-provider-auth0#435
When creating an auth0_custom_domain resource, subsequent runs of terraform apply attempt to destroy and recreate the same resource over and over. It appears that verification_method is not being set in the remote state, and is also set to ForceNew, meaning that terraform constantly sees it as an update and constantly tries to reapply.
Terraform 0.13.5
+ provider.auth0 0.21.0
resource "auth0_custom_domain" "login" {
domain = var.login_domain
type = "auth0_managed_certs"
verification_method = "txt"
}resource should cleanly apply
resource reapplies every time.
terraform applyterraform applyterraform applyterraform applyterraform applyFrom terraform-provider-auth0 created by nirvdrum: alexkappa/terraform-provider-auth0#269
Please add more logging to help debug connection issues. I've been having problems importing a new tenant. Even with TF_LOG set to TRACE and the Auth0 provider's debug setting set to true, I couldn't see why I couldn't connect. I just received a 401 message about oauth2 not being able to connect. In this particular case, it turns out my domain was wrong*, so there weren't any logs in the Auth0 dashboard either.
I was only able to figure out the issue after building the provider myself with several debug statements.
* - US-based tenants used to go to ".auth0.com", but now go to ".us.auth0.com". Some part of our TF config assumed the old naming convention and thus couldn't connect to a newly created tenant.
Any resource that makes an API call.
I don't think any new configuration is needed. Reporting the URL on error without any extra configuration would be a big help. If that's too noisy, however, showing connection info when the debug flag is set would be very helpful.
From terraform-provider-auth0 created by ScottBouloutian: alexkappa/terraform-provider-auth0#344
Hi, I am trying to use the adfs strategy for the auth0_connection resource. The documentation lists this as a valid strategy, however when I try to use it there is a warning that reads "Unsupported connection strategy adfs". I have narrowed this down to the expandConnection function in structure_auth0_connection.go. Is this an issue or is there something that I am missing?
From terraform-provider-auth0 created by galkin: alexkappa/terraform-provider-auth0#381
auth0_branding
Terraform 0.14.10
+ provider.auth0 0.21.0
resource "auth0_branding" "my_brand" {
logo_url = "https://mycompany.org/logo.png"
favicon_url = "https://mycompany.org/favicon.ico"
colors {
primary = "#0059d6"
page_background = "#000000"
}
}The second terraform apply will not affect resource
Every terraform apply update resource by deleting font.
From terraform-provider-auth0 created by willvedd: alexkappa/terraform-provider-auth0#505
Implement a user data source in the provider to allow for easier management of Auth0 users when unable to manage through Terraform directly. This ticket stems from the closure of #429.
From terraform-provider-auth0 created by galkin: alexkappa/terraform-provider-auth0#388
This is quote from documentation:
You can prevent sending the email addresses on the redirect links by updating the email templates using the Management API. For example:
PATCH /api/v2/email-templates/reset_email { "includeEmailInRedirect": false } or,
PATCH /api/v2/email-templates/verify_email { "includeEmailInRedirect": false }
We have this feature at gopkg.in/auth0.v5 from go-auth0/auth0 5.8.0, but we don't have the provider
resource "auth0_email_template" "my_email_template" {
template = "welcome_email"
body = "<html><body><h1>Welcome!</h1></body></html>"
from = "[email protected]"
result_url = "https://example.com/welcome"
subject = "Welcome"
syntax = "liquid"
url_lifetime_in_seconds = 3600
enabled = true
depends_on = [ "${auth0_email.my_email_provider}" ]
// added
include_email_in_redirect = true
}N/A
From terraform-provider-auth0 created by mattmillen888: alexkappa/terraform-provider-auth0#337
Have these features been deprecated?
refresh_token {
infinite_idle_token_lifetime = true
infinite_token_lifetime = false
idle_token_lifetime = 1296000
}
as i now get:
An argument named "infinite_token_lifetime" is not expected here.
An argument named "idle_token_lifetime" is not expected here.
An argument named "infinite_idle_token_lifetime" is not expected here.
when i do terraform plan
From terraform-provider-auth0 created by atellezr: alexkappa/terraform-provider-auth0#385
When importing a connection object, the options are not imported.
I had a database connection defined in the Auth0 tenant, and I wanted to import it in Terraform. The database has custom scripts defined in the tenant, and what I wanted is to import everything related to that object into my local terraform configuration.
If I use the nodejs CLI (auth0-deploy-cli) I can get the connection configuration, including the options and, among others, the custom scripts.
And if I invoke directly the API /api/v2/connections/con_AAAAAAAAAAAAAAAA I can see the options with its attributes as well.
$ terraform -v
Terraform v0.14.4
+ provider registry.terraform.io/alexkappa/auth0 v0.20.0
(although there's a newer version, the v0.21.0, checking the code there are no significant differences related to the options object itself)
At the moment of executing the import, the configuration that I have in Terraform related to the connection is only this one:
resource "auth0_connection" "my_connection" {}I expect to import the options attribute with all its attributes (mfa, customScripts, ...), as part of the import process of the whole object.
The options attribute is imported as an empty array. No child attributes are imported
Prepare the Terraform configuration object (see Terraform Configuration Files section)
Executed the import command:
$ terraform import auth0_connection.my_connection con_AAAAAAAAAAAAAAAA
auth0_connection.my_connection: Importing from ID "con_AAAAAAAAAAAAAAAA"...
auth0_connection.my_connection: Import prepared!
Prepared auth0_connection for import
auth0_connection.lp_users: Refreshing state... [id=con_AAAAAAAAAAAAAAAA]
Import successful!
The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.
terraform state show auth0_connection.my_connection), I don't see the options attribute. In the Terraform state file I see the object as an empty array: {
"mode": "managed",
"type": "auth0_connection",
"name": "my_connection",
"provider": "provider[\"registry.terraform.io/alexkappa/auth0\"]",
"instances": [
{
"schema_version": 2,
"attributes": {
"display_name": null,
"enabled_clients": [
...
],
"id": "con_AAAAAAAAAAAAAAAA",
"is_domain_connection": false,
"name": "MyConnection",
"options": [],
...
https://gist.github.com/atellezr/c8e336df73e3575ebf58e87f8ab4c676
Not applicable
No, nothing remarkable
N/A
From terraform-provider-auth0 created by smhamza24: alexkappa/terraform-provider-auth0#495
When creating auth0_connection with strategy waad the login button doesn't appear on login page until we go to auth0 dashboard and manually set "Display connection as a button" checkbox.
resource "auth0_connection" "aad" {
name = "microsoft-azure-AD"
strategy = "waad"
options {
waad_common_endpoint = false
tenant_domain = "test.com"
identity_api = "microsoft-identity-platform-v2.0"
client_id = "asdfasdfafsd"
client_secret = "asfasdf"
//something like following could be helpful
display_connection_as_button = true
display_connection_as_button_label = "Login with AD"
display_connection_as_button_logo = "https://my.domain/logo.png"
}
enabled_clients = [auth0_client.my_new_app.id]
}From terraform-provider-auth0 created by squarebracket: alexkappa/terraform-provider-auth0#247
I have created two auth0_connection resources, with strategies auth0 and google-oauth2.
They create just fine, but when destroying, I get the error:
Error: json: Unmarshal(nil)
for both of them. The resources are deleted from auth0 but remain in the terraform state, so I'm guessing it's a failure in decoding the API response.
Terraform v0.12.24
+ provider.auth0 v0.11.0
+ provider.aws v2.68.0
+ provider.digitalocean v1.20.0
+ provider.null v2.1.2
resource "auth0_connection" "users" {
name = "Development"
strategy = "auth0"
enabled_clients = [
# list of clients
]
}
resource "auth0_connection" "google" {
name = "google"
strategy = "google-oauth2"
enabled_clients = [
# list of clients
]
options {
client_id = "client_id"
client_secret = "client_secret"
scopes = [
"email",
"profile",
]
}
}The resources are destroyed successfully
The resources are deleted from auth0, but the resources remain in the terraform state.
terraform apply -auto-approveterraform destroy -auto-approveThis is part of a bigger terraform. I looked through the TRACE level logs and didn't see anything relevant.
From terraform-provider-auth0 created by alexkappa: alexkappa/terraform-provider-auth0#465
Most resources documentation includes a section called Attribute Referece. This should list any attribute that was computed during terraform apply. IDs are often missing from this list of attributes as they are not defined in the resource schema.
So for any resource that implicitly uses IDs, it should be documented.
Almost all resources
<!-- docs/resources/organization.md -->
## Attributes Reference
In addition to the arguments listed above, the following computed attributes are
exported:
+ * `id` - Organization ID
* `version_id` - Version ID of the deployed action. This value is available if `deploy` is set to true
From terraform-provider-auth0 created by wcislo-taxy-io: alexkappa/terraform-provider-auth0#492
Support for session_cookie argument in auth0_tenant resource.
As of right now management API allows for controlling this setting.
From terraform-provider-auth0 created by FlowFlorent: alexkappa/terraform-provider-auth0#408
Hello!
As per the title mentions, adding secrets after hook creation does not seem to work.
What has been tested:
Modifying an already setup secrets works:
secrets = {
my_var = "old_value"
}secrets = {
my_var = "new_value"
}Adding a secret to an existing hook does not:
secrets = {
my_var = "value"
}secrets = {
my_var = "value"
my_new_var = "value"
}Output from our actual plan:
~ secrets = (sensitive)
# (4 unchanged attributes hidden)
Terraform `0.15.5`
provider.auth0 `0.21.0`
# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a [Github Gist](https://gist.github.com/) instead.Adding new secrets to an existing auth0_hook should work.
Adding new secrets does nothing.
auth0_hookresource "auth0_hook" "my_hook" {
name = "my-hook"
script = file("${path.module}/hooks/hooks/post-user-registration/my-hook.js")
trigger_id = "post-user-registration"
enabled = true
secrets = {
foo = "foo"
}
}my_hook by adding a new secret:resource "auth0_hook" "my_hook" {
name = "my-hook"
script = file("${path.module}/hooks/hooks/post-user-registration/my-hook.js")
trigger_id = "post-user-registration"
enabled = true
secrets = {
foo = "foo"
bar = "bar"
}
}bar) is not added in auth0From terraform-provider-auth0 created by L-Sypniewski: alexkappa/terraform-provider-auth0#461
Add the ability to set 'Fixed Length of Access Token & Authorization Code' flag in Tenant Settings
resource "auth0_tenant" "my_org" {
name = "my_org"
display_name = "My Organization"
fixed_length_access_token_and_authorization_code = true
}From terraform-provider-auth0 created by epintos: alexkappa/terraform-provider-auth0#427
I'd like to request support for Log Stream filters parameters
# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.From terraform-provider-auth0 created by willvedd: alexkappa/terraform-provider-auth0#506
Implement a user_roles resource in the provider to allow for easier management of Auth0 users when unable to manage through Terraform directly. This ticket stems from the closure of #429.
From terraform-provider-auth0 created by kvrhdn: alexkappa/terraform-provider-auth0#230
The documentation on terraform.io/docs does not mention anything about importing resources. But I found out by looking in the code that it is indeed supported.
Could we add documentation to clarify this? It was for instance not super clear to me at first that I had to import a resource by its ID (which I can't find in the Auth0 UI...) instead of by its name.
I would expect something similar to the AWS provider, for example: https://www.terraform.io/docs/providers/aws/r/db_instance.html#import
From terraform-provider-auth0 created by mdreizin: alexkappa/terraform-provider-auth0#493
# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.
resource "auth0_connection" "test" {
name = "test"
display_name = "Test"
strategy = "oidc"
show_as_button = true
options {
client_id = "client-id"
discovery_url = "https://example.com/.well-known/openid-configuration"
icon_url = "https://example.com/icon.png"
}
}I have already contacted Auth0 support and asked them to add that options.
For now you can try to go https://auth0.com/docs/api/management/v2/#!/Connections/post_connections and use the following body to test it:
{
"strategy": "oidc",
"options": {
"client_id": "client-id",
"discovery_url": "https://example.com/.well-known/openid-configuration",
"icon_url": "https://example.com/icon.png"
},
"name": "test",
"display_name": "Test",
"show_as_button": true
}From terraform-provider-auth0 created by abbaspour: alexkappa/terraform-provider-auth0#460
Auth0 now allows PKCE on oauth2 strategy. auth0_connection does not support it yet. This is how it would look like:
resource "auth0_connection" "connection" {
name = "my-custom-social-connection"
strategy = "oauth2"
options {
client_id = "XXXX"
client_secret = "XXXX"
authorization_endpoint = "https://example.com/authorize"
token_endpoint = "https://example.com/token"
scopes = ["scope1"]
scripts = {
fetchUserProfile = data.template_file.fetchUserProfile.rendered
}
pkce_enabled = true // <-- HERE
}
enabled_clients = [
auth0_client.sample_client.id
]
}
From terraform-provider-auth0 created by sunnz: alexkappa/terraform-provider-auth0#428
Is it possible to set an environment tag like development, staging, and production in terraform?
When logging in to auth0 through the web it is under tenant settings, general.
From terraform-provider-auth0 created by brandonbirdj: alexkappa/terraform-provider-auth0#442
Please add support for the flag disable_management_api_sms_obfuscation to the auth0_tenant
# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.From terraform-provider-auth0 created by RishikeshDarandale: alexkappa/terraform-provider-auth0#477
auth0_action secrets most probably do not support the update/delete of existing secrets. But, adding new is supported and this functionality is not working at this moment with resource auth0_action.
Terraform v1.0.11
on linux_amd64
+ provider registry.terraform.io/alexkappa/auth0 v0.24.2
+ provider registry.terraform.io/hashicorp/local v2.0.0resource "auth0_action" "test-action" {
name = "test"
supported_triggers {
id = "pre-user-registration"
version = "v2"
}
code = file("test.js")
runtime = "node16"
dependencies {
name = "Dep1"
version = "v1"
}
dependencies {
name = "Dep2"
version = "v2"
}
secrets {
name = "SOME_KEY"
value = "SOME_VALUE"
}
deploy = true
}terraform import should get the secret key read into the state fileterraform apply should add the new secret to the actionaction having one secretaction with one secretaction to add a new secretNote: In all cases,
terraform(internally auth0 mgmt API) should not be deleting/updating existing secrets.
Above observation is based on the events that were recorded #470 as below.
terraform import is not importing the secret with only key into terraform stateterraform apply is not passing the new secrets to HTTP PATCH call for action update.terraform applyPlease refer #470 and #472 for more debug details!
From terraform-provider-auth0 created by WilliamABradley: alexkappa/terraform-provider-auth0#213
This allows you to re-use existing roles and attach permissions to them. This is helpful if you have roles in a Tenant, and multiple applications, that you want to attach permissions to the Role.
Attaching a Role to an existing User is also a useful resource.
resource "auth0_role_permission_attachment" {
role = "USER"
resource_server_identifier = auth0_resource_server.audience.identifier
permission = "VIEW:USER"
}
resource "auth0_user_role_attachment" {
role = "USER"
user_id = "12345"
}From terraform-provider-auth0 created by btilford: alexkappa/terraform-provider-auth0#343
In the case permissions aren't automatically added for the management api the provider needs to be configured to request the scopes it needs.
provider "auth0" {
domain = "<domain>"
client_id = "<client-id>"
client_secret = "<client-secret>"
debug = "<debug>"
scopes = [
"read:client_grants",
"delete:client_grants",
"create:client_grants",
]
}From terraform-provider-auth0 created by srenatus: alexkappa/terraform-provider-auth0#233
Terraform v0.12.24
The resource settings don't include idle_session_timeout right now, so it's
resource "auth0_tenant" "dev-tenant" {
friendly_name = "Dev Tenant"
# number of hours a session is valid
session_lifetime = 12
}In auth0's management UI, it's set to 30 minutes:
It should not explode 😉
# terraform apply -auto-approve
module.tenant.auth0_tenant.dev-tenant: Refreshing state... [id=terraform-20200512113443006900000001]
module.webapp.auth0_client.local-webapp: Refreshing state... [id=BQpS1FDWpIU5iw779X63gvB3f2LFM6h2]
module.connection.auth0_connection.main-connection: Refreshing state... [id=con_j4zs05ANTO69Yj7U]
Error: json: cannot unmarshal number 0.5 into Go struct field Tenant.idle_session_lifetime of type int
terraform applyFrom terraform-provider-auth0 created by rajdeeprspl: alexkappa/terraform-provider-auth0#393
Hi There,
Can you please help me on the below described issue ?
I am getting this error while applying terraform plan or trying to import resources.
**_Error: invalid character '<' looking for beginning of value_**
But executing terraform validate its showing validation success .
Same code with different credentials working for a tenant but not to other one.
Is it something that I am missing ?
auth0_connection.google: Importing from ID "con_xxxxxxxxxxxxx"...
auth0_connection.google: Import prepared!
Prepared auth0_connection for import
auth0_connection.google: Refreshing state... [id=con_xxxxxxxxxx]
Error: invalid character '<' looking for beginning of value
I am also attaching terraform trace log in here.
Many Thanks.
rajdeep
From terraform-provider-auth0 created by dev-usa: alexkappa/terraform-provider-auth0#430
When setting up Auth0 connection of type SAML, it does not seem possible to specify the signing_key object.
This is supported by the API as explained here - https://auth0.com/docs/protocols/saml-protocol/saml-sso-integrations/sign-and-encrypt-saml-requests#use-custom-certificate-to-sign-requests
"signing_key": {
"key": "",
"cert": ""
}resource "auth0_connection" "test_connection" {
name = "enterprise-saml-connection"
strategy = "samlp"
options {
signing_key = {
key = file("${path.module}/x509.pem")
cert = file("${path.module}/x509.pem")
}
}I am new to golang and also open source contribution.
I did some digging and found some places where things need to change, like in connection.go, there is a struct ConnectionOptionsSAML that needs to be updated in the repo [email protected]:go-auth0/auth0.git with the signing_key attribute. However, I am not sure how to create a PR for that repo. (not seeing any instructions / markdown pages in there)
Also, given I am a new, I am not sure how to open a PR with the changes to this repo itself.
Appreciate suggestions.
Thank you
From terraform-provider-auth0 created by ns0092: alexkappa/terraform-provider-auth0#334
0.12.29
Auth0 Provider version = 0.14.0
resource "auth0_connection" "testing_google_connection" {
name = "testing-google-com"
strategy = "google-apps"
is_domain_connection = "false"
options {
name = "testing-google-com"
domain = "test-google.com"
client_id = jsondecode(data.aws_secretsmanager_secret_version.<secret_name>.secret_string)["client_id"]
client_secret = jsondecode(data.aws_secretsmanager_secret_version.<secret_name>.secret_string)["client_secret"]
api_enable_users = "true"
disable_signup = "false"
brute_force_protection = "true"
}
}Creation of Google connection on auth0
Error: 400 Bad Request: undefined is not a valid google apps domain
terraform apply2021-02-16T14:42:45.443-0800 [DEBUG] plugin.terraform-provider-auth0_v0.14.0_x4: 2021/02/16 14:42:45 [DEBUG] setting computed for "options.0.password_history" from ComputedKeys
2021-02-16T14:42:45.444-0800 [DEBUG] plugin.terraform-provider-auth0_v0.14.0_x4: 2021/02/16 14:42:45 [DEBUG] setting computed for "options.0.password_history" from ComputedKeys
2021-02-16T14:42:45.444-0800 [DEBUG] plugin.terraform-provider-auth0_v0.14.0_x4: 2021/02/16 14:42:45 [DEBUG] setting computed for "enabled_clients" from ComputedKeys
2021-02-16T14:42:45.444-0800 [DEBUG] plugin.terraform-provider-auth0_v0.14.0_x4: 2021/02/16 14:42:45 [DEBUG] setting computed for "realms" from ComputedKeys
2021-02-16T14:42:45.445-0800 [DEBUG] plugin.terraform-provider-auth0_v0.14.0_x4: 2021/02/16 14:42:45 [WARN]: Unsupported connection strategy google-apps
2021-02-16T14:42:45.445-0800 [DEBUG] plugin.terraform-provider-auth0_v0.14.0_x4: 2021/02/16 14:42:45 [WARN]: Raise an issue with the auth0 provider in order to support it:
2021-02-16T14:42:45.445-0800 [DEBUG] plugin.terraform-provider-auth0_v0.14.0_x4: 2021/02/16 14:42:45 [WARN]: https://github.com/terraform-providers/terraform-provider-auth0/issues/new
2021/02/16 14:42:45 [DEBUG] auth0_connection.testing_google_connection: apply errored, but we're indicating that via the Error pointer rather than returning it: 400 Bad Request: undefined is not a valid google apps domain
Unsupported connection strategy google-appsFrom terraform-provider-auth0 created by willvedd: alexkappa/terraform-provider-auth0#513
Originally spurring from #351 which was closed due to the project migration.
From the OP:
This modification makes it such that tenant setting flags will only be included in the PATCH /api/v2/tenants/settings call if they have changed. This proposed change addresses use cases for Auth0 private cloud and enterprise customers whose tenants do not allow updates of certain tenant settings flags. Even the mere presence of these flags in the API call, irrespective of the values changing or not, will cause the API to return an error response. With these proposed changes, the tenant setting flags will simply be omitted from the API call if unchanged, thus bypassing the issue altogether.
This issue, while appearing to be straightforward, is non-trivial to holistically address. I defer to the comments in #351 for explanation.
This would also fix #160 .
From terraform-provider-auth0 created by ertanden: alexkappa/terraform-provider-auth0#413
We are using this module to configure roles etc for users which are imported (so not created by this plugin). Our users are created in Auth0 automatically from another identity provider connection.
However we are facing issues with the case sensitivity of the user_id.
I think the root cause is the StateFunction in the User resource which always converts the user_id to lowercase.
So this for us results in change detection for our user resources even though there's no change actually.
Is there a specific reason why the StateFunc is defined to always convert user_id's to lowercase?
From terraform-provider-auth0 created by larryboymi: alexkappa/terraform-provider-auth0#362
It would be helpful if upstream_params were exposed in the options block for a connection, to help in the case of desired extra parameters, or modifying existing parameters, such as login_hint. We have some integrations with Auth0 where the login_hint is actually somewhat harmful to the user experience, and aliasing it to a different parameter has helped us get around it. Unfortunately, the option isn't present in this provider yet, but having it would help greatly in these cases.
Please see the bottom of this resource for the proposed upstream_params option.
resource "auth0_connection" "saml" {
for_each = {
for conn in var.saml_connections : conn.name => conn
}
name = each.value.name
display_name = each.value.display_name
strategy = "samlp"
enabled_clients = local.enabled_clients[each.value.enabled_app_env]
options {
sign_in_endpoint = each.value.sign_in_endpoint
sign_out_endpoint = each.value.sign_out_endpoint
signing_cert = each.value.signing_cert != null ? filebase64("${path.module}/${each.value.signing_cert}") : null
sign_saml_request = true
signature_algorithm = "rsa-sha256"
digest_algorithm = "sha256"
protocol_binding = "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
domain_aliases = each.value.domain_aliases
fields_map = each.value.fields_map
upstream_params = {
alt_username = {
alias = "login_hint"
}
}
}
}From terraform-provider-auth0 created by alexkappa: alexkappa/terraform-provider-auth0#190
From terraform-provider-auth0 created by larryboymi: alexkappa/terraform-provider-auth0#361
When importing a client with the provider, it does not pull in addon-related data, such that a plan for terraform and a client having addons will think that a change/modify is necessary to get in-line with what is present in Auth0 for the client.
Terraform v0.14.9
+ provider.auth0 v0.20.0
dynamic "addons" {
for_each = each.value.logout_callback == null ? [] : [each.value.logout_callback]
content {
samlp {
audience = each.value.audience
logout = {
callback = each.value.logout_callback
}
map_unknown_claims_as_is = true
}
}
}When running a terraform import for a given client, it would be nice if the addons were imported as well, such that a subsequent terraform plan does not try to modify an existing client for which addons already exist.
terraform planAfter an import, a subsequent plan of a client having addons looks like the following
+ addons {
+ samlp {
+ audience = "https://my-url"
+ create_upn_claim = true
+ digest_algorithm = "sha1"
+ include_attribute_name_format = true
+ lifetime_in_seconds = 3600
+ logout = {
+ "callback" = "https://my-saml-logout"
}
+ map_identities = true
+ map_unknown_claims_as_is = true
+ name_identifier_format = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
+ passthrough_claims_with_no_mapping = true
+ signature_algorithm = "rsa-sha1"
+ typed_attributes = true
}
}From terraform-provider-auth0 created by red8888: alexkappa/terraform-provider-auth0#403
auth0_client_grant allows us to create a specific grant, but I want to fully control and track all grants made for an app or api. It makes sense to have a resource named like auth0_client_grants that takes a map/list of all grants configured for an application (or maybe api or make it configurable).
So if a user manually adds a grant terraform would see that change against the list of grants in the diff. Also, we could import an auth0_client_grants resource and it would find and reconcile all grants.
From terraform-provider-auth0 created by abbaspour: alexkappa/terraform-provider-auth0#459
In auth0_client, default for jwt_configuration.alg is HS256 which is not best practice. appreciate if you can change the default to RS256 is future.
From terraform-provider-auth0 created by yinzara: alexkappa/terraform-provider-auth0#365
The Auth0 Passwordless Email and SMS connection options both support an "authParams" attribute that's a key value pair map of string->string. It is currently implemented in the auth0 go library, but not in the terraform provider
resource auth0_connection "sms" {
name = "sms"
strategy = "sms"
options {
auth_params = {
scope = "openid profile mycustomscope"
}
}
}I could not find any reference to this configuration parameter in Auth0 Documentation but it is definitely available via the Management API.
From terraform-provider-auth0 created by mijdavis2: alexkappa/terraform-provider-auth0#254
With auth0 provider v0.12.2, samlp addon for "auth0_client" resource no longer works when mapping isn't defined.
tf = v0.12.6
auth0 provider = v0.12.2
resource "auth0_client" "idp" {
provider = auth0.idp
name = "MyApp IDP"
description = "MyApp IDP"
app_type = "regular_web"
callbacks = [
"https://${var.env_name}.us.auth0.com/login/callback?connection=sso-idp",
"https://${var.env_name}.us.auth0.com/login/callback",
"https://${var.env_name}.us.auth0.com/login",
"https://${var.env_name}.us.auth0.com/p/samlp/sso-idp",
]
web_origins = [
"https://${var.env_name}.us.auth0.com",
]
addons {
samlp {
recipient = "https://${var.env_name}.us.auth0.com/login/callback?connection=sso-idp"
audience = "urn:auth0:${var.env_name}:sso-idp"
logout = {
callback = "https://${var.env_name}.us.auth0.com/logout?connection=sso-idp"
}
}
}Create auth0_client without errors
module.auth0.auth0_client.idp: Creating...
Error: 400 Bad Request: Payload validation error: 'Expected type array but found type null' on property addons.samlp.nameIdentifierProbes. (also) Payload validation error: 'Expected type object but found type null' on property addons.samlp.mappings.
on .terraform/modules/auth0/main.tf line 9, in resource "auth0_client" "idp":
9: resource "auth0_client" "idp" {
[terragrunt] 2020/07/16 10:32:47 Hit multiple errors:
exit status 1
terraform applyFrom terraform-provider-auth0 created by lebaptiste: alexkappa/terraform-provider-auth0#279
Aside Terraform resources, there is also another data source type which is roughly the readonly version of a resource.
That would be a great enhancement to this provider to include data source support. Since I have already worked on a terraform provider I am happy to submit a PR for it.
Ideally all the existing resources would have their data source counterpart.
From terraform-provider-auth0 created by jowparks: alexkappa/terraform-provider-auth0#496
Auth0 scopes added via Auth0 UI work correctly, but when the same scope is added via terraform, the returned token doesn't have the expected scopes:
In UI Configuration:
In Terraform Configuration:
Token received from UI configuration:
Token received from terraform configuration:
(Can't do running on remote CI machine)
provider.auth0 alexkappa/auth0 v0.25.0
[2022-01-14T22:30:05.811Z] Terraform will perform the following actions:
[2022-01-14T22:30:05.811Z]
[2022-01-14T22:30:05.811Z] # module.auth0_snowflake_server.auth0_resource_server.resource_server will be updated in-place
[2022-01-14T22:30:05.811Z] ~ resource "auth0_resource_server" "resource_server" {
[2022-01-14T22:30:05.811Z] id = "61e1d6cf92dfc1003f27f880"
[2022-01-14T22:30:05.811Z] name = "Snowflake resource for data platform"
[2022-01-14T22:30:05.811Z] # (9 unchanged attributes hidden)
[2022-01-14T22:30:05.811Z]
[2022-01-14T22:30:05.811Z] + scopes {
[2022-01-14T22:30:05.811Z] + description = "Change Snowflake Roles during session"
[2022-01-14T22:30:05.811Z] + value = "SESSION:ROLE-ANY"
[2022-01-14T22:30:05.811Z] }
[2022-01-14T22:30:05.811Z] }
scope should be returned in access_token from Auth0
Empty permissions list is returned
Add scope definition in terraform to resource_server definition, then request token with the audience of that resource_server
From terraform-provider-auth0 created by WellBloud: alexkappa/terraform-provider-auth0#503
If I create an action with post-user-registration trigger, it will get created as an action with Login / Post login trigger.
resource "auth0_action" "post_reg_action" {
name = "Post registration action"
supported_triggers {
id = "post-user-registration"
version = "v2"
}
deploy = true
code = ""
}
When deployed, it looks like this:
It shouldn't say Login / Post login, but rather Post User Registration.
Also, if you try to bind this into a Flow, it will fail with following error:
╷
│ Error: 400 Bad Request: Trying to create a binding between an incompatible action and trigger.
│
│ with auth0_trigger_binding.post_user_registration_flow,
│ on flowPostRegistration.tf line 2, in resource "auth0_trigger_binding" "post_user_registration_flow":
│ 2: resource "auth0_trigger_binding" "post_user_registration_flow" {
│
The code for the binding:
resource "auth0_trigger_binding" "post_user_registration_flow" {
trigger = "post-user-registration"
actions {
id = auth0_action.post_reg_assign_roles_action.id
display_name = auth0_action.post_reg_assign_roles_action.name
}
}
Terraform v1.1.4
on linux_amd64
+ provider registry.terraform.io/alexkappa/auth0 v0.26.1
It should create an Action ready to be used in Post-registration flow
It creates an Action in Login flow
terraform applyFrom terraform-provider-auth0 created by yarinm: alexkappa/terraform-provider-auth0#486
I'm trying to create a SAML connection with the following fields_map (which is valid if I create it via the API):
{
"name": [
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"
],
"email": [
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"
],
"given_name": [
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
],
"samlGroups": [
"groups",
"http://schemas.microsoft.com/ws/2008/06/identity/claims/groups"
],
"family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
}
For some reason fields_map in the provider is defined as a simple map of strings:
"fields_map": {
Type: schema.TypeMap,
Elem: &schema.Schema{Type: schema.TypeString},
Optional: true,
Description: "If you're configuring a SAML enterprise connection for a non-standard PingFederate Server, you must update the attribute mappings.",
},
It would be nice if the elem schema could be a string or list of strings or better yet just make this a JSON field
From terraform-provider-auth0 created by tarfeef102: alexkappa/terraform-provider-auth0#436
Currently, samlp configurations have to be specced-out by field, which is tedious and painful. However, auth0 has an answer for this: metadata importing. If we could use this API and provide an XML or URL for the provider to fetch and compare to state, then configurations could be much simpler. This is especially helpful if you're working with third parties who may change their metadata configuration and expect you to pick up the changes and act on them without active collaboration.
resource "auth0_connection" "example" {
name = "Example-Connection"
strategy = "samlp"
options {
metadataUrl = "https://some_site.com/some_doc.xml"
}or
resource "auth0_connection" "example" {
name = "Example-Connection"
strategy = "samlp"
options {
metadataXml = data.local_file.xml.content
}From terraform-provider-auth0 created by hoppalotta: alexkappa/terraform-provider-auth0#397
Auth0 clients of the "SSO Integration" type don't appear to be supported at this time. The specific case I'm trying to solve for is an integration with Tableau Server, see links below. Thanks for publishing and maintaining this provider and also for your consideration on this issue!
auth0_client
resource "auth0_client" "tableau" {
name = "Tableau Server"
app_type = "sso_integration"
...
}
From terraform-provider-auth0 created by art-i-svsg: alexkappa/terraform-provider-auth0#358
When running initial terraform apply - resources are created normally. When running apply again after successful first run, getting following on all resources:
Error: Get "https://smth.us.auth0.com/api/v2/hooks/id": oauth2: cannot fetch token: 500 Internal Server Error
Response: {"error":"server_error","error_description":"Script generated an unhandled asynchronous exception."}
And this error appears for every Auth0 resource previously created.
Terraform v0.13.5
+ provider registry.terraform.io/alexkappa/auth0 v0.19.0
+ provider registry.terraform.io/hashicorp/template v2.2.0
Tried v0.14.7 of TF as well - same result.
Here is how provider is configured:
terraform {
backend "s3" {
bucket = "***"
key = "auth0/***"
region = "us-east-1"
encrypt = true
}
}
provider "auth0" {
domain = var.domain
client_id = var.client_id
client_secret = var.client_secret
}
Any new changes should be applied.
Errors appear all the time and unable to apply any changes.
terraform applyFrom terraform-provider-auth0 created by bourbonfgiles: alexkappa/terraform-provider-auth0#509
Hello,
I was looking at your provider.tf and I see you specify the tenant. Could I specify multiple tenants in separate provider blocks or is only one per repo supported?
Thanks,
Ben.
From terraform-provider-auth0 created by red8888: alexkappa/terraform-provider-auth0#400
If a setting isn't defined in the terraform config it seems like the provider just ignores out of band changes. This is an issue especially for importing resources. For example when importing existing tf resources I'll frequently just create a minimal config, import the existing resource to that config, then run plan and add in all the settings from the diff- instead of having to manually try to eye-ball all the settings of the existing resource and plugin them in.
Terraform v0.14.4
+ provider registry.terraform.io/alexkappa/auth0 v0.21.0
resource "auth0_client" "derps" {
name = "test"
description = "testing"
}terraform a new auth0_client and leave all optional settings blank. Modifying the app in the UI after its deployed and run terraform plan again. Should see a diff of the changes that were made out of bound.
After terraforming a new auth0_client, changes made to that client ("application") are not tracked by terraform.
terraform a new auth0_client resource leaving all optional settings blank. Manually modify the grants of that application in the auth0 UI. Run plan again and terraform will say there are no changes.
From terraform-provider-auth0 created by ccogan-lh: alexkappa/terraform-provider-auth0#491
When defining a tenant, I provide the flags.enable_client_connections parameter and have it be false. Terraform applies with no issue, but within the Auth0 console I see this is toggled to true. Terraform does not see the delta and says no issue. I can manually flip the state on Auth0 and Terraform still does not see the issue.
╰─ terraform -v
Terraform v1.1.2
on darwin_amd64
resource "auth0_tenant" "project" {
picture_url = "https://project.com/images/main-logo.png"
support_email = "[email protected]"
flags {
enable_client_connections = false
}
}New tenant should exist with client_connections = disabled
New tenant exists client_connections = true and does not properly track deltas
terraform applyN/A ?
N/A
From terraform-provider-auth0 created by yinzara: alexkappa/terraform-provider-auth0#364
When upgrading to the most recent version of the provider, I received a panic during a terraform plan that crashed the provider
0.12
Running most recent version from master
panic during terraform plan
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: panic: interface conversion: interface is nil, not interface {}
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0:
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: goroutine 153 [running]:
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: github.com/alexkappa/terraform-provider-auth0/auth0.connectionSchemaUpgradeV1(0xc0007fc600, 0x1c6eee0, 0xc0002e38c0, 0xc0007fc600, 0x0, 0x0)
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: /Users/yinzara/github/terraform-provider-auth0/auth0/resource_auth0_connection.go:675 +0x43a
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: github.com/hashicorp/terraform-plugin-sdk/internal/helper/plugin.(*GRPCProviderServer).upgradeJSONState(0xc000796008, 0x0, 0xc0007fc600, 0xc0000bf440, 0xc0007eaff0, 0x0, 0x0)
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: /Users/yinzara/go/pkg/mod/github.com/hashicorp/[email protected]/internal/helper/plugin/grpc_provider.go:395 +0xb7
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: github.com/hashicorp/terraform-plugin-sdk/internal/helper/plugin.(*GRPCProviderServer).UpgradeResourceState(0xc000796008, 0x1f729d0, 0xc0004cce40, 0xc0008d9200, 0xc000796008, 0xc0004cce40, 0xc0005b1ba0)
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: /Users/yinzara/go/pkg/mod/github.com/hashicorp/[email protected]/internal/helper/plugin/grpc_provider.go:270 +0x28f
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: github.com/hashicorp/terraform-plugin-sdk/internal/tfplugin5._Provider_UpgradeResourceState_Handler(0x1d3b5e0, 0xc000796008, 0x1f729d0, 0xc0004cce40, 0xc00081f5c0, 0x0, 0x1f729d0, 0xc0004cce40, 0xc000ed4000, 0xb0d)
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: /Users/yinzara/go/pkg/mod/github.com/hashicorp/[email protected]/internal/tfplugin5/tfplugin5.pb.go:3233 +0x214
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: google.golang.org/grpc.(*Server).processUnaryRPC(0xc0000181c0, 0x1f7ca18, 0xc0006c3200, 0xc0000c9200, 0xc00083a780, 0x25bb7e0, 0x0, 0x0, 0x0)
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: /Users/yinzara/go/pkg/mod/google.golang.org/[email protected]/server.go:1180 +0x52b
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: google.golang.org/grpc.(*Server).handleStream(0xc0000181c0, 0x1f7ca18, 0xc0006c3200, 0xc0000c9200, 0x0)
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: /Users/yinzara/go/pkg/mod/google.golang.org/[email protected]/server.go:1503 +0xd0c
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: google.golang.org/grpc.(*Server).serveStreams.func1.2(0xc0008341c0, 0xc0000181c0, 0x1f7ca18, 0xc0006c3200, 0xc0000c9200)
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: /Users/yinzara/go/pkg/mod/google.golang.org/[email protected]/server.go:843 +0xab
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: created by google.golang.org/grpc.(*Server).serveStreams.func1
2021-04-04T21:48:17.308-0700 [DEBUG] plugin.terraform-provider-auth0: /Users/yinzara/go/pkg/mod/google.golang.org/[email protected]/server.go:841 +0x1fd
2021-04-04T21:48:17.311-0700 [DEBUG] plugin: plugin process exited: path=/Users/yinzara/.terraform.d/plugins/terraform-provider-auth0 pid=32447 error="exit status 2"
I was able to fix this by changing line 671 of resource_auth0_connection from:
if !ok {
to
if !ok || v == nil {
I will submit a PR
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.