Suppose you are adding an enterprise SSO connection to an existing Ambassify community. In that case, chances are that the users in your own database (Azure AD, Okta, ...) are already in the Ambassify community. You probably want to let those users keep their existing Ambassify account and start logging in using your SSO.
Let's take a look at what factors come into play here:
Whether or not you are using our auto-registration features
Whether or not the SSO profile sent to Ambassify contains any of our unique identifiers: e-mail address and telephone number.
Whether or not the value from one of those identifiers is present in an Ambassify profile
If you are not using auto-registration
If you aren't using our auto-registration feature, your users won't be able to log in using SSO automatically. Existing Ambassify users need to go to their profile to connect their SSO profile. If they are not in Ambassify yet, you need to send them an invite message to get them in. (See below for a list of solutions that help you get the profiles connected.) This is the most straightforward way but has the disadvantage of requiring you to manually invite new members instead of letting anyone with an SSO profile into Ambassify automatically.
When using auto-registration
When auto-registration is enabled, anyone who logs in to Ambassify with the SSO connection will be able to access the community, whether they had an account in Ambassify already or not. If they didn't have an account yet, one will be created for them automatically - hence the name auto-registration.
If the SSO profile we receive from you on login doesn't contain any of our unique identifiers, we can't check if the users from your database match one in our database so a new account will always be created for anyone who logs in for the first time using the SSO connection. Unless you've used the bulk-connect (explained later) to connect every member, this option is undesirable as those existing Ambassify members who weren't bulk-connected will end up with two accounts, and merging accounts isn't impossible.
If the SSO profiles do contain either the e-mail address or phone number, what happens depends on whether or not there is an Ambassify profile with matching values:
When the e-mail address or telephone number matches. The system will show an error when the user tries to log in using the SSO connection. This happens because there is already a user with that unique identifier in our system.
When the e-mail address or telephone number doesn't match. A new user account is created.
Neither of those scenarios is something you want to end up in. In our opinion, the best way to go is to keep supporting the old login methods and only enable auto-registration after all your current Ambassify users have connected their SSO profiles.
Tools to help you get SSO profiles connected
We offer a few tools and flows to help you get your existing members connected to their SSO profiles.
Custom property: "SSO Connected"
We can add an "SSO Connected" custom property to your account that automatically gets set to "Yes" when a member has connected their SSO profile. This way you can use it to filter your members to see who hasn't connected yet and send them a message, for example, to ask them to connect.
This service is included for free when setting up Enterprise SSO.
Bulk-connect SSO profiles
What we can also do is bulk-connect the SSO profiles for you. It requires you to deliver us a CSV file that contains a row for each of your Ambassify members.
The data per member should include at least:
Either their Ambassify ID or one of their other key identifiers so we can match it against the Ambassify profile
The ID on their SSO profile. For example:
For SAML: the value of the
NameIDproperty in the SAML assertionsFor OIDC: value for the
sub,user_idoridfield in the JWT claims...
If this is an avenue you want to take, do make sure to check with your own SSO team if such a list can be provided beforehand.
This service is included for free one time when setting up Enterprise SSO.