Recent Content
Launching on Khoros Communities Session #3: Executing the Launch | Instructor-Led Training
We are excited to announce live training on Executing the Launch in Khoros Communities are coming in February 2025! Tuesday, April 1, 2025 Early Session: 7 am CDT / 1 pm UTC Late Session: 3 pm CDT / 9pm UTC Engagement communities play a vital role in retaining and keeping your customers satisfied in an ever-changing digital world. Khoros Communities Aurora delivers a sleek, modern, and high-performance system that adheres to community best practices while still giving brands complete flexibility to make changes or updates to address their ongoing needs. In this session, focussed on the Execution and Launch phases of the launch/upgrade process, you will learn about: The 3 main tracks running concurrently through the Execution Phase The User Acceptance Testing (UAT) process and the final Launch Phase Internal resources needed and how best to prepare for the Execution and Launch Phases Whether you are preparing for your upgrade to or launch on Khoros Communities Aurora or simply learning more about the process, we are here to help. Missed the first two sessions in this series? Review the Q&A and access recordings through the following links. Launching on Khoros Communities Session #1: Why Khoros Communities Aurora? Launching on Khoros Communities Session #2: Preparing to LaunchAurora: Configure remote site access for your Salesforce integration
The Aurora/Salesforce integration must be able to access your Khoros community. Part of this integration involves mentioning community APIs in the allowed list so Salesforce doesn't block them. To configure remote site access: In your Salesforce.com environment, go to Setup. Go to Administration Setup > Security Controls > Remote Site Settings. By default, two Remote Site Settings with the NameSpace prefix "LiSFintegration" appear. For the Khoros (Lithium) setting, click Edit. Enter the Base URL value according to your Khoros environment. Note: Be sure to include the https:// and HT credentials. Use the following format: https://<HTUSER>:<HTPASSWORD>@<***Community URL> Example: https://test123:qwerty98765@community-stage.khoros.com/ Khoros Community Stage Base URL Sandbox https:// [community_id].stage.lithium.com Production https:// [community_id].lithium.com Note: Your Khoros Community Success Manager (CSM) can provide you with your Community ID. Note: If you have a more descriptive CNAME/vanity address for your community, use that name when creating the URL (for example, https://community.mycwebaddress.com). (Optional) For debugging purposes, you can turn-off the requirement for HTTP communication. While this is not recommended in any production-like environment due to security risks, it may assist in diagnosing connectivity issues. After your diagnostics are complete, we strongly advise re-enabling HTTPS and maintaining it for security reasons. Click Save. Click Edit for the SFSelf setting and provide the Remote Site URL as your existing signed-in Salesforce URL (for example, https://na16.salesforce.com). Click Save. Repeat steps 3 – 9 for your production community, replacing the name with something descriptive such as “Khoros community – Production” and the URL with the final URL for your production community (for example, https://community.mywebaddress.com). Note: You can also repeat this process to connect multiple Khoros communities to your Salesforce instance. For custom domains (Salesforce 3.9 or later): Click New Remote Site. Enter SFSelfInstance for the Remote Site Name. Enter your Remote Site URL (for example, "yourinstance.salesforce.com"). Enter a Description for this site. Select the Active checkbox. Click Save.About Aurora OIDC/OAuth2.0 SSO
OpenID Connect (OIDC) is an SSO implementation based on OAuth2. Refer to the official OpenID Connect specs for more information. OIDC Quick Start Common OpenID Connect terms: OP = OpenID Provider, also known as the Identity Provider (IDP) RP = Relying Party, also known as the Service Provider (SP) OpenID Connect typically follows this workflow: User requests to sign in. User is redirected to OP’s sign-in URL, and OP redirects the user to the RP with an authorization code sent as a query parameter value. RP sends a back-channel request to the OP’s token API with the OP-provided authorization code to retrieve the ID and Access Tokens. The ID Token is retrieved from the token response and is parsed as a JSON Web Token (JWT). The JWT is validated and decoded. (JWT validation should follow the signature specified in the OpenID Connect specifications.) The JSON payload is retrieved from the JWT and is parsed for claims to be set to the user’s community profile. If a user profile endpoint is configured, an additional call is made to the endpoint passing the access token using Bearer Authorization. (OIDC feature supports both GET and POST requests to the user profile endpoint. This is configured within the Provider settings.) Claims returned from the user profile endpoint are parsed and set to the user’s community profile based on configured Claim Mappings. Community checks to see if the user already exists with the specified SSO ID; if so, the user signs in to an existing account; if not, a new account must be created. User resumes browsing Khoros Community in signed-in state. OAuth 2.0 typically follows this flow: User clicks the sign-in/registration link or takes an action that requires sign-in. User is redirected to a Khoros endpoint that builds the IDP/OP's sign-in URL based on configured attributes and the user state (that is, the page they were on when they initiated sign-in), and then redirects the user to the built sign-in URL. User signs in or registers. If the app is not on the allow list, the user will be prompted to give access to the Aurora Community app. The user is redirected to a callback URL on Community and an authorization code is included in the request as a query parameter. Community reads the authorization code. Community makes a back-channel API call to the OAuth provider to exchange the authorization code for ID and access tokens. The ID Token is retrieved from the token response and is parsed as a JSON Web Token (JWT). Optionally, the access token is then passed using Bearer Authorization in a subsequent API call to obtain additional user attributes such as SSO ID, e-mail address, display name, etc. Community checks to see if the user already exists with the specified SSO ID; if so, the user signs in to an existing account; if not, a new account must be created. User resumes browsing Khoros Community in signed-in state. Enable OIDC/OAuth 2.0 SSO for the Aurora Community Before you begin setting up OpenID Connect SSO for Community, you must gather this information: Client ID Client Secret Authorization Endpoint URL Token Endpoint URL (OIDC only) Expected “Issuer” for JWT validation (OIDC only) JWKS URI pointing to sign-in keys Claims mapping to map the minimum Community profile attributes to claims returned by the Token Endpoint URL and/or User Info URL. The required attributes that must be mapped are: SSO ID Login Name Email Address Note: When adding Claim Mapping during Provider Creation, the keys for the above values are “ssoid,” “login,” and “email,” respectively. After you have gathered the information listed above, you must create a Provider within the Community. Note: For a detailed description of all the OIDC/OAuth 2.0-related provider settings, review Aurora OpenID Connect/OAuth 2.0 setting descriptions. To create a Provider: Go to Settings > System > Account > OIDC/OAuth Providers > Add Provider. For each tab, enter this information: Name: Used to more easily distinguish a given provider in the UI. ID: Used in the Community sign-in URL, sign-out URL, and callback URL to distinguish between each provider configuration. Check out the examples below to see how these URLs are constructed. Client ID: Determined by the app created in your OP. Client Secret: Determined by the app created in your OP. Authorization: Enter authorization URL, Response Type, and Scope. Token: Token endpoint URL, expected Issuer, and JWKS URI. In addition, claim mapping must be added either here. The required profile attributes mentioned above must be mapped to an associated claim for SSO to function properly. For example, if the “sub” claim will be used for SSO ID, beside Claim mapping (ssoid required), click Add Parameter. Then enter “ssoid” into the Key field, and “sub” into the Value field. User Info: Fill in if any claim mappings come from a user info endpoint. Insert the user info URL and add any claim mapping. Click Create. When creating the app in the OP, you might be asked to specify a callback URL. The callback endpoint uses this format: https://<communityhost>/t5/s/auth/oauth2callback/providerid/<providerid> For example, if a Community at https://community.acme.com was configured with Provider ID “acme,” the URL would be: https://community.acme.com/t5/s/auth/oauth2callback/providerid/acme Note: If your Aurora community is configured for Reverse Proxy with Subdirectory, your endpoint paths are pushed up into the reverse proxy path similar to other URLs in your community. Enable SSO When you have finished your OAuth or OIDC configuration and you are ready to test, in the Single Sign On (SSO) section, turn on Use Khoros single sign-on (SSO). For more information, see Configure SSO settings for the community. Related topics: Aurora OpenID Connect/OAuth2.0 setting descriptionsAurora: Configure SSO settings for the community
Before you can use SSO with your community, you need to configure settings and enable the option. Note: As soon as you turn on the Use Khoros single sign-on (SSO) option, all the settings in the Single Sign-On area become active in the community. To configure SSO settings and enable SSO: Go to System > Account & Privacy. Scroll down to the Single Sign-On (SSO) section. Manage the following options: Allow member to change their SSO email address: Enable members using SSO to change the email associated with their account. This should be enabled only if the email address is collected on the Community SSO Registration screen. Allow member to change their first name and last name: Enable SSO users to update their first and last names under My Preferences > Personal. Use auto sign-in for fallback SSO: When Khoros SSO token-based sign-in fails, auto sign-in is used instead. Enter the following SSO URLs: Registration page: Direct users to this URL when they register. Sign-in page: Direct members to this URL when they sign in. Sign-out page: Direct members to this URL when they sign out. Bounce URL: (Optional) URL where the first request of a session is redirected. Can help to enable seamless Community authentication or "Bounce SSO". Leave blank to disable. Enter the Return value parameter name. By default, the Aurora Community application appends a query string parameter named referer (spelled as shown) and a value corresponding to the URL of the page the member was browsing prior to being redirected to the login or registration page. If your authentication system is already configured to use a parameter like “referer,” you can change “referer” to the name of that parameter. Otherwise, leave the parameter name as “referer.” Turn on Use Khoros single sign-on (SSO) to make these settings active in the community. Note: This must be enabled in order for any configured SSO mechanisms to be fully functional, including when using the multi-auth Sign-in Display feature detailed in Multi-Auth SSO. URL formats SAML (REDIRECT BINDING) Sign-in URL: <Aurora url>/t5/s/<communityID>/auth/saml/doauth/redirect Sign-out URL: <Aurora url>/t5/s/<communityID>/auth/saml/dologout/redirect SAML (POST BINDING) Sign-in URL: <Aurora url>/t5/s/<communityID>/auth/saml/doauth/post Sign-out URL: <Aurora url>/t5/s/<communityID>/auth/saml/dologout/post OIDC SSO Sign-in URL: <Aurora url>/t5/s/<communityID>/v1/auth/oidcss/sso_login_redirect/provider/<providerID> Sign-out URL: <Aurora url>/t5/s/<communityID>/v1/auth/oidcss/sso_logout_redirect/provider/<providerID> Related topics: About Khoros Aurora Single Sign-On (SSO) Khoros Aurora SSO auto-sign in MultiAuth SSOAurora: Multi-Auth SSO
Communities require diverse authentication methods to accommodate varying member segments like employees, customers, etc. Admins can offer multiple sign-in options simultaneously, providing enhanced flexibility. These options include: Khoros SSO Up to three IDPs for SAML More than three IDPs for OIDC/OAuth2 (OIDC can be configured via admin only) To edit these settings, go to Settings > Systems > ACCOUNT > Sign-in. If Sign-In Display is not displayed, contact Khoros Support and request that the Multi-Auth feature be enabled. Edit the Sign-In Display option to configure the sign-in options you want to provide your members and how you want to display the sign-in options. Below is an example on the list of sign-in options you can configure. From here, you can: View all available sign-in options for your community. Add a welcome note that is displayed to users on the sign-in page. Turn on or off the sign-in options you prefer. Edit the labels of the sign-in buttons. Rearrange the order in which the sign-in options appear on sign-in pages. Choose to display the sign-in options as buttons for member sign-in. If you select the Display as sign-in button option, members see a sign-in button. If you de-select this option, members see a sign-in form instead. Enable SSO When you have finished your OAuth or OIDC configuration and you are ready to test, in the Single Sign On (SSO) section, turn on Use Khoros single sign-on (SSO). For more information, refer to Configure SSO settings for the community. Related topics: About Khoros Aurora Single Sign-On (SSO) Khoros Aurora SSO auto-sign in Configure SSO settings for the communityAurora Community static IP addresses
A variety of Aurora Community integrations may require allowlisting IP addresses associated with requests to external resources or services. Some example integrations include: API Event Subscriptions (webhooks) Certain types of SSO, like OAuth 2 or OpenID Connect Custom Freemarker components using the http.client context object Custom back-end integrations built by Professional Services If your Community-related security architecture includes IP based allowlists, the following values can be used: AMER production AMER stage 34.218.217.104 35.167.51.70 34.208.76.195 35.155.246.43 35.155.246.68 52.41.143.85 EMEA production EMEA stage 52.213.102.195 52.214.128.6 34.246.41.42 52.51.95.11 34.246.43.26 52.208.187.165 APAC production APAC stage 54.206.152.214 3.105.80.217 52.65.188.98 3.105.88.113 13.239.46.46 13.55.41.72 Note: The listed IP addresses are associated only with outbound requests from Community and are not valid for inbound requests to the Community. Community IPs used with inbound requests are variable and change over time. Do not use these IPs as an element of any DNS record. If you're unsure if your Community is hosted in the AMER, EMEA, or APAC region, contact Khoros Support.Aurora: Set date ranges and data comparison time frame for the Analytics Dashboard
Analytics users can: choose the time frame for which they want to view metrics for compare and analyze data with another time period Note: By default, dashboards display data for the entire community for the last 30 days. To set a specific date range or date: To view or compare data for specific date ranges Select the date range using the dashboard date-range menu. Select one of the following from the menu. By default, the date range is set to Last 30 days for all dashboards. Last 7 days: Data for the previous 7 days from the current date Last 30 days: Data for the previous 30 days from the current date Last month: Data for the first to last day of the previous calendar month Last 3 months: Data for the first to last day of the last 3 calendar months Month to date: Data for the first date of the current calendar month to current date Year to date: Data for the first date of the current year to current date Specific date: Data for any specific date Custom: Data for any range of dates. To select a specific date range, click Custom from the date picker. On the window, select the starting and ending days on the calendar. After you select the dates, click Set Date Range. The dashboard displays data for the date range selected. To set a comparison time frame: Use the Data Comparison Time Frame settings to gain insights into how your community has performed over time. Previous period: Compares the currently selected period in the dashboard settings to the previous matching period. For example, if the current period is Last 30 days, the comparison is to the previous 30 day period. Previous year: Compares the current selected period to the same period last year. For example, if the current period is Last 7 days, the dashboard displays comparison data for the matching dates last year. Note: All the trend graph widgets have the checkbox for Previous Period or Previous Year, depending on the dashboard settings. When you select the checkbox, the data for the comparison time frame is displayed. Here’s an example to better understand the comparisons: Assume today is January 1, 2023, and the currently selected period for the chart is Last 7 days: Comparison Time Frame Current dates Comparison dates Previous period December 25, 2022 to December 31, 2022 December 18, 2022 to December 24, 2022 Previous year December 25, 2022 to December 31, 2022 December 25, 2021 to December 31, 2021 Related topics: About Aurora Analytics Aurora Analytics Metric Definitions Aurora Analytics Reports
