Single Sign-on (SSO) is a feature that allows log-in credentials to be shared across multiple systems to reduce repeated log-in operations.
For example, users can sign in to a customer's system and, from there, access a Higher Logic Vanilla (Vanilla) community without having to separately log in to Vanilla. The credentials that were provided to the customer's system serve as the access credentials for Vanilla because they were already authenticated by the IdP (Identity Provider).
📝 NOTE: All communications between SSO-enabled systems are secure; so is the identity of the user moving between them.
SSO support in Vanilla
Vanilla supports several SSO solutions. Use the links below to access our knowledge base articles.
Vanilla also offers:
- Social SSO (social-media and other sites; see Social Connect Options)
- Third-party service integration (e.g., Auth0; cloud-only)
- Custom SSO integrations (cloud-only)
All SSO solutions follow general rules in Vanilla, many of which are outlined below.
General SSO principles
Regardless of which SSO solution you use, the following principles and recommendations apply to ensure that your SSO works well with Vanilla.
- You are the provider so you must make sure that the information you pass through SSO is already validated. For example, email addresses should be already confirmed on your side before a user is allowed to connect through SSO.
- It is recommended you do not create users over the API. The fault-tolerant way to map users to your community is to have them be asynchronously created as they log in.
Account connection
All of Vanilla's SSO methods support Just-In-Time (JIT) provisioning. This means that if a user does not already exist in our system, one is automatically provisioned upon the first connection.
When a user logs in through SSO for the first time, a connection is made using the SSO UniqueID and Vanilla UserID. The connection between the two IDs is permanent for that connection. If the user changes their email address after the first connection it won’t cause any problem.
When that connection is being made, if:
All the required information is correctly passed through SSO and a matching user is found in Vanilla...
- A new user is created in the community.
Some required information is missing... OR
Some information matches an existing user on the community...
- The user will be redirected to a page and must do one of the following:
- Provide the missing information.
- Manually connect to an existing community account by specifying the password of that account. (This ensures that the user owns the community’s account.)
- Create an account with a username/email address that does not exist in community.
📝 NOTE: A prompt will display if the user omits any required information.
AutoConnect
AutoConnect is a feature that uses email addresses to automatically connect an account in the Account connection process. When this feature is enabled and the email address that is passed through SSO matches the email address of a user account in the community, the connection between the SSO UniqueID and Vanilla UserID is immediate, the user does not have to confirm ownership over an existing account.
- For security reasons, it must be opted into. Email addresses must be validated on your side when using this feature.
- Vanilla connects existing accounts only by matching email address. No exceptions.
Redirection
📝 NOTE: Most SSO solutions honor this behavior.
When tightening your SSO configurations to automatically redirect users after the sign-in process, you can use {target} in the redirect URL. Vanilla will replace {target} with the page that the user is currently viewing when generating the URL.
EXAMPLE (using jsConnect):
https://sso.example.com/jsconnect/signin?redirect={target}
might be updated to:
https://sso.example.com/jsconnect/signin?redirect=/discussions
User log outs
Log out initiated from Vanilla
We recommend using the default logout approach, which is accomplished by:
- Setting a default connection (having your SSO connection as the only method for connecting users to the community) and
- Including your site's log-out URL in its configuration.
When users click Sign Out on Vanilla, they are logged out of the community and redirected to your site's log-out page.
Log out initiated from your site
You can set up the log out such that when users log out of your site, they are also automatically logged out of your community.
There are two ways to have this happen: redirecting and deleting cookies. Both of these methods require:
- having a shared domain (or subdomain) and
- modifying your Cookie Domain.
To understand shared domain, assume that your site is thisismysite.com and that your community is forum-now, your shared domain is forum-now.thisismysite.com.
Because your site and community share the domain, you can set the Cookie Domain on the community as *.thisismysite.com.
📝 NOTE: Modifying your Cookie Domain requires the assistance of the Vanilla Support Team.
Now when the user is on thisismysite.com, you can read and/or delete cookies that were set on forum-now.thisismysite.com.
Redirecting and deleting cookies are the two ways of logging users out of your site and automatically out of your community.
Redirecting
When users sign out of your site, they are redirected to the community log-out page with the TransientKey (which is stored in their cookies) and the Target (the URL-encoded destination of where you would like users to end up after being logged out).
Below is an example of a URL with these parameters and their values.
https://forum-now.thisismysite.com/entry/signout?TransientKey=59WaY3nFTSHLiDWN%3A33%3A1585763045%3Abfb7f6e3cd8dda34095a441dcba52f1f&Target=https%3A%2F%2Fthisismysite.com%2Fthank-you-come-again.
📝 NOTE: Specify the Target URL in the Trusted Domains section of the Security page in Dashboard > Settings > Technical.
Deleting cookies
When users sign out of your site, as part of your session-ending routine, you can delete all the Vanilla-generated cookies.
