[CXP-295] fix: support authSetting profile field as fallback when IDP discovery fails

[luisina-santos]

Summary

• Adds authSetting as an optional account profile field in CreateAccount
• When IDP auto-discovery yields no result (e.g. site-auth-configurations returns 404 on older on-premises Tableau Server <2023.3), the caller can now pass "authSetting": "SAML" (or "OPENID") in the profile to control the auth method directly
• Without this fallback, Tableau defaults to TableauIDWithMFA when no idpConfigurationId is provided — wrong for customers using SAML/Okta (CXP-295, Zscaler)

Context

This is a follow-up to the v0.1.9 fix (commit 8c28935) which absorbed the 404 from site-auth-configurations gracefully. That fix stopped the hard failure but introduced silent wrong behavior: users were provisioned with TableauIDWithMFA instead of the site's SAML IDP.

Test plan

• BUG-03 reproduced on v0.1.9: --api-version 3.21 forces 404 → user created with authSetting=TableauIDWithMFA (wrong)
• FIX-05 verified on this branch: same --api-version 3.21 + "authSetting":"SAML" in profile → sync confirms authSetting=SAML
• FIX-03 regression: normal IDP discovery still works when endpoint is available (sync confirms authSetting=SAML via idpConfigurationId)
• No change to withMFA=true path or multi-IDP error path

QA plan: https://www.notion.so/31f4694ad846811db45be8d39ab5a7ca

🤖 Generated with Claude Code

[github-actions]

Claude finished @luisina-santos's task in 1m 30s —— View job

---

PR Review: authSetting fallback support

• Gather context and read changed files
• Review code changes
• Post review feedback

---

Overall: Looks good. The change is minimal, well-placed, and solves a real problem for older on-prem Tableau Server environments where IDP discovery isn't available.

What works well

• Correct fallback ordering: The else if placement ensures IDP auto-discovery is always attempted first, and authSetting is only used when discovery returns nothing — this avoids any regression for environments where the endpoint works.
• Minimal blast radius: 5 lines added, no structural changes, no new dependencies.
• Good comment: The inline comment clearly explains when and why this branch is taken.

Suggestion: validate authSetting value

The authSetting value from the profile is passed directly to the Tableau API without validation. The codebase already has isAllowedAuthSetting() in pkg/client/helpers.go:115 that validates against ["SAML", "OPENID"]. Consider using it to reject invalid values early with a clear error, rather than letting Tableau return a potentially confusing API error:

} else if authSetting, _ := pMap["authSetting"].(string); authSetting != "" {
    if !client.IsAllowedAuthSetting(authSetting) {
        return nil, nil, nil, fmt.Errorf("baton-tableau: unsupported authSetting %q (allowed: SAML, OPENID)", authSetting)
    }
    reqBody.AuthSetting = authSetting
}

This would require exporting isAllowedAuthSetting (capitalize it), but it's a small change that improves the user experience. That said, this is a minor nit — Tableau's API will reject invalid values regardless, so the current code is functionally correct.

Fix this →

No issues found

• No regressions to the withMFA path or multi-IDP error handling
• The CreateUserRequest.AuthSetting field already has omitempty, so when neither path sets it, the field is correctly omitted from the API request
• The type assertion pMap["authSetting"].(string) safely handles missing/wrong-type values via the blank identifier

---

[linear]

CXP-254 baton-github-enterprise Connector -

CXP-295 Tableau Connector: viewer license provisioning failing due to IDP 404