It would be great if we could have Constant Contact users authenticate using SAML. Right now, there's no way to enforce authentication policy (like MFA) to users with access to the account. Likewise, it would be helpful if we could auto provision/de-provision users using this integration
Thanks for sharing this feedback with us. What are some cases where the current authentication options we provide do not fit your needs? In the meantime we will continue to collect both requests along with use case examples.
1. With the current setup, each individual user is responsible for enabling MFA for their individual user account. It’s not currently possible to A) enforce MFA across the constant contact account determine if users have MFA enabled C) determine if the users password is compliant with org policy. The admin needs to “chase” the users to enable MFA, and the user then needs to maintain a separate form of MFA for Constant Contact. Likewise, there is no way to enforce a particular password policy to be compliant with the org’s standards. Additionally, the current setup requires that users must maintain a separate set of credentials, which adds complexity and complication to the existing setup and makes it more challenging for our users to adopt secure authentication practices.
With SAML Single Sign-On (SSO), users A) could be required to login through their Identity Provider (IdP) (Okta/Google Workspace, Azure AD etc.), don’t need to maintain a separate username/password/MFA and C) admins can ensure/attest that their constant contact accounts are secured according to policy because authentication has been set at the IdP level.
2. With regards to auto provision/deprovision, the use case would be essentially A) Being able to auto create Constant Contact users based on role (so for example marketing group), and when they get provisioned with the IdP and go to login to Constant Contact their account gets created. Being able to deprovision/delete users who are disabled from our IdP rather than having to log into the separate system and disable the user in both places.
Thanks for following up with these details! While single sign-on or the option of enforcing or accessing the MFA of your sub-users are not available features we have tracked your feedback on this to the appropriate teams on your behalf.
We would love to see this as well. Also, for those who won't implement SSO, the option for the primary account to make MFA mandatory for users and specify the types available. (So that companies that cannot implement SSO can at least ensure a form of MFA is configured on every account on their instance and they can ensure the form that is implemented meets their security standards.)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Our Feedback board is changing! From updated statuses to clearer processes, we're working to improve the conversation between you and our Product teams