Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add User ID Attribute Type for AzureAD Connections #1006

Open
1 task done
u771385 opened this issue Aug 21, 2024 · 2 comments
Open
1 task done

Add User ID Attribute Type for AzureAD Connections #1006

u771385 opened this issue Aug 21, 2024 · 2 comments
Labels
🌱 feature New feature or request

Comments

@u771385
Copy link

u771385 commented Aug 21, 2024

Checklist

Describe the problem you'd like to have solved

Need to be able to set the User ID Attribute Type on Azure AD Connections to oid to support SCIM. My existing connections that were provisioned through TF were all defaulted to sub.

Describe the ideal solution

One idea would be to extend the user_id_attribute used for samlp connections and allow either oid or sub for AzureAD connections.

Alternatives and current workarounds

None. Any update to the Connection will cause a null to be passed to the userid_attribute field which will reset the value back to sub - even though it retrieved the value as "oid" in the GET just before the PATCH.

Additional context

No response

@u771385 u771385 added the 🌱 feature New feature or request label Aug 21, 2024
@stevemao
Copy link

This seems to be a bug rather than a feature

@michael-mcguinness
Copy link

Agree that this is a bug.

From an API view (GET https://tenant.eu.auth0.com/api/v2/connection) the userid_atrribute property is not visible until it has been explicitly set in some way. In our case, while investigating the issue, we set the value to oid and then back to sub via the console. If we then made an API call to view the resource we can see the the userid_attribute property and can see that it is set to sub.

The next time we perform a terraform apply the property gets set back to null. Any subsequent terraform plan shows an intention to set this back to sub but it stays as null when viewed via the API.

 # module.terraform-auth0-tenant.auth0_connection.connections["connection_aad"] will be updated in-place
  ~ resource "auth0_connection" "connections" {
        id                   = "<redacted>"
        name                 = "<redacted>"
        # (5 unchanged attributes hidden)

      ~ options {
          + user_id_attribute                      = "sub"
            # (37 unchanged attributes hidden)
        }
    }

Plan: 0 to add, 1 to change, 0 to destroy.

We assume that despite this showing as null the underlying behaviour is sub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🌱 feature New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants