Recent Content
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 communityAbout Content permissions
You can adjust permissions related to content at the community, container (category & group), and board level. Some permissions are set to Deny by default while others are set to Grant by default. At the container level and the board level, permission defaults and role permissions are inherited from the parent level. In those cases, the Inherit button is displayed in green to indicate that the permission was set to Grant at the parent level or red to indicate that the permission was set to Deny at the parent level. As an admin, you can manage these permissions. To manage content-related permission defaults at the community level: Note: To manage this permission at a lower level, go to the [Place] Permissions page and edit the permission defaults for that level. To manage this permission for a particular role, go to the [Place] Permissions page at the desired level of the community and edit the permissions of the individual roles. Go to the Roles and Permissions page for the community. Beside Community Permissions Defaults, select Edit. Review permissions in the following areas: Blogs Content Events Ideas Knowledge Bases Select Deny or Grant as required. Unless you have specified different permissions for certain roles or levels below the community level (a category, group, or board), these selections affect all members of the community. Content permissions While Forum permissions are granted by the Content permissions, Blogs, Event Boards, Ideas boards, and Knowledge Bases have distinct permission sections for content type-specific tasks. The Content permissions are provided for general content access and tasks and relate to all content types. Follow the links in the table below to learn more about the tasks granted by these permissions. Permission Default Related permissions in content type sections Read discussions and content Grant Blogs: Read posts and Read comments Ideas: Read ideas and comments Reply to discussions and content Grant Blogs: Comment on posts Events: Comment on events Ideas: Comment on ideas Knowledge Bases: Comment on articles Start discussions and new content Grant Blogs: Start new posts Events: Post new events Ideas: Post new ideas Knowledge Bases: Create, edit, publish, and manage articles Edit own posts Deny Blogs: Edit own published posts Events: Edit own events Ideas: Manage ideas and comments Knowledge Bases: Edit own published articles Edit any post Deny Blogs: Edit any published post Events: Edit all events Ideas: Manage ideas and comments Knowledge Bases: Edit any published article Move content Deny Blogs: Manage any posts and Manage own posts Delete own post Deny Blogs: Manage own posts Events: Delete own events Knowledge Bases: Delete own articles Delete any post Deny Blogs: Manage any posts Events: Delete all events Ideas: Manage ideas and comments Upload file attachments Deny Embed external content Grant Use simple HTML in posts Grant Use advanced HTML in posts Deny Use full HTML in posts Deny Make content read only Deny Post read-only content Deny Bypass moderation Deny Blogs: Bypass comment moderation Events: Bypass comment moderation Ideas: Bypass moderation Knowledge Bases: Bypass comment moderation Related topics: About Aurora Community site structure About Aurora Content TypesAurora 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
