About Aurora badge rules and supported criteria
For each community badge you want to create, you must define the rule that determines how a member achieves or receives the badge. For simpler rules, you can use the built-in tool that enables you to select a criterion and additional qualifiers. However, if you want a more complex rule for a badge, you can use the Advanced Editor to enter badge formulas. Badge formulas include a combination of a formula clause type, a keyword, an operator, and a value. When the calculation of a value in a formula returns a true result, the member achieves the badge. The badge achievement is then reflected in their profile and badges page. To create more complex badge rule expressions that require multiple rules be met before awarding a badge, you can use the “AND” operator. Common use cases for badges with multiple rule criteria include profile completion tasks and more complex engagement options. For example, you may want to award a “VIP Contributor” badge to members who: Have received at least 100 likes Have had at least 25 answers marked as Accepted Solutions Have posted at least 10 blog articles Tip: You can also use community roles as an additional requirement for any badges based on activity. By taking advantage of the “unlocking” game dynamic, you can set certain badges to be earnable only after a community member has reached a rank that grants them the required role. Create a complex badge rule Go to Settings > Users > Badges. To add a rule to a badge in an existing badge set, click the name of the badge set that contains the desired badge and then click Add Badge. Otherwise, create a new badge set where you want the badge with complex rules to live (see Create badge sets and badges). After entering the badge Name, Description, and Icon, in the Criteria drop-down menu, select Advanced Editor. In the Advanced Editor field, enter your custom badge rules. Enter each rule you want met (making sure that each rule has an identifier, operator, and value). Enter AND between each rule. Select the Hide from member profile until earned checkbox to ensure that the badge is displayed on member profiles only when the rules are met. Click Add Badge. Let’s say you want to create a badge for new members to encourage them to begin participating in the community. You might create a rule like this: metric.net_overall_threads >= 5 AND metric.net_kudos_weight_received >= 20 AND metric.net_accepted_solutions >= 3 This complex rule may be great for a badge that rewards users for creating new content with great quality. Feel free to use this example for your own community! Note: You cannot create complex rules with OR or NOT. Supported badge clauses and badge criteria A badge formula can include one of five types of clauses depending on the type of behavior you want to reward. You can chain rules together to create complex criteria using these clause types: Metric: Assigns a badge based on the value of a specific community activity recorded for each member. Member in role: Assigns a badge to a set of members based on community-level roles. User ID in set: Assigns a badge to a manually specified set of members based on their numeric user ID. This should be reserved for awarding rare badges to a small group of members. Non-Default profile setting value: Assigns badges based on members changing the default state of a specific setting or profile field on their member profiles. Specific profile setting value: Assigns badges based on the member changing a setting in their profile to a specific value. (For example, you could award a badge when a member sets their profile language to French.) Clause Type Clause Format (variables in bold) Metric metric.name_of_metric >= number Example: metric.net_accepted_solutions >= 1 Roles user.role.name in ['role'] Example: user.role.name in ['Administrator', 'Khoros'] User ID user.id in [id] Example: user.id in [10, 2, 5] Non-default profile setting setting.setting_key != 'default' Example: setting.profile.location != 'default' Profile setting value setting.setting_key = '[value]' Example: setting.profile.location = 'Argentina' Rewarding user activity using metrics For definitions of exactly what these metrics are, refer to these Aurora Analytics Metrics Definitions. The following member activity metrics are supported for use in a badge formula using the format: metric.name_of_metric >= [number] Accepted Solutions metric.net_accepted_solutions All Content Types metric.net_overall_posts metric.net_overall_replies metric.net_overall_threads Blogs metric.net_blog_articles metric.net_blog_comments metric.net_blog_posts Forums metric.net_posts metric.net_threads metric.net_replies Ideas metric.net_idea_threads metric.net_idea_comments metric.net_idea_posts Images and video metric.image_upload_count metric.video_upload_complete_count Likes metric.net_kudos_weight_given metric.net_kudos_weight_received Message views metric.message_views Sign-ins metric.logins KBs metric.net_published_tkb_articles metric.net_tkb_comments Rewarding specific members You can award badges to a specific group of members based on their role or user ID. Since you can’t edit a rule after you create the badge, we recommend using roles as the basis of your rule criteria. That way, if you need to add or remove members later, you can modify the member list for the role independent of the badge rule criteria. Important: If you want members to be notified (via email or real-time notifications) of a role-based badge, you must roll out the badge first and then add the role for that member. If the member already has the role before the badge is published, the member will not be notified. Keep in mind: Newly created badges are automatically applied to all members who already match the criteria, resulting in email notifications being sent out to community members depending on your badge notification settings. You need to coordinate such badge releases with Khoros to avoid a surge of emails being sent out to the community members, which can impact your community performance. Use single quotes around the role name. Use commas if you enter more than one. For example, to award a badge to all members with the “Admin” or “Moderator” role, enter this rule criterion: user.role.name in [‘Admin’, ‘Moderator’] You should use "user ID in set" in badge criteria only if you have a static, unchanging list of specific members. This clause type should be used only in special cases to award badges for one-time achievements. Otherwise, you’ll need to delete and recreate the badge each time you want to add another member’s user ID to the rule. Use commas if you enter more than one. For this case, use this format: user.id in [10,2,5] Rewarding profile completion You can use the profile setting below to create badges that reward members for filling out more information about themselves in their profile. These settings can all be used with the "Non-default profile settings" clause. Profile setting identifier Setting name Setting location setting.profile.name_first First Name My Settings > Personal setting.profile.name_last Last Name My Settings > Personal setting.profile.location Location My Settings > Personal setting.profile.biography Bio My Settings > Personal > Bio setting.profile.url_homepage Personal Site My Settings > Personal avatar_changed Note: To award a badge when a member changes their default avatar image, use this syntax: avatar_changed = true Avatar My Settings > Personal > Edit Rewarding date-based activity You can award badges based on date-based activities. Setting identifier Setting options Examples consecutive sign-ins number setting.user.max_consecutive_logins >= 2 registration_date date registration_date > "2015-01-01" (see supported syntax options below) time_since_registration time value in days, months, or years time_since_registration >= "1 years" signin_date date signin_date > "2015-01-01" (see supported syntax options below) About sign-in related activity We store a counter of the number of days in a row and the last sign-in time. When someone signs in, we get the date of the last increment and the date of today, and we count the days between. If < 1, we ignore it (so no gaming the system). If == 1, we increment the day counter. If > 1, we set the day counter to 0. About entering dates You can enter dates (which must be in quotes) in all formats supported by ISO 8061: Year: YYYY (eg 1997) Year and month: YYYY-MM (eg 1997-07) Complete date: YYYY-MM-DD (eg 1997-07-16) Complete date plus hours and minutes: YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00) Complete date plus hours, minutes and seconds: YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00) Complete date plus hours, minutes, seconds and a decimal fraction of a second YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00) where: YYYY = four-digit year MM = two-digit month (01=January, etc.) DD = two-digit day of month (01 through 31) hh = two digits of hour (00 through 23) (am/pm NOT allowed) mm = two digits of minute (00 through 59) ss = two digits of second (00 through 59) s = one or more digits representing a decimal fraction of a second TZD = time zone designator (Z or +hh:mm or -hh:mm) Note: When an ISO 8601 date doesn't specify a time zone, it is considered to represent local time. We do not override the local time zone for this purpose, so the date is parsed from the badge clause based on the server's local time zone. So that will differ depending on the AWS region: US-West-2 (PST) EU-West-1 (CET) To prevent confusion on the Internet, date strings (for example, in badge clauses) may specify a time zone. Related topics: About Badges and Badge sets Create badge sets and badges Feature badge sets on the member profile Delete badge sets and badges Example badge sets and badges View badges from the member profileAbout Aurora Email Notifications
As a community member, you receive email notifications for different types of activity across the community. To manage your email notification preferences, see Manage Follow and Notification preferences for your account. Email notification triggers Email notifications may be sent in a variety of situations. Some may require action while others may be purely informational. Below are descriptions of the notifications you may receive. More email notification types will be available in future releases. Community member notifications Content Workflow notifications Admin-only notifications Community member notifications Notification Description New Accepted Solution A post is marked as a solution on a topic a community member is following Accepted Solution Reminder Reminder to check answers on content and to mark applicable posts as solutions Answer Accepted as Solution A post is marked as a solution on a topic a community member created New Follow (Digest) Daily or weekly digest that provides updates from the community member’s followed content New Follow (Immediate) Immediate notification that provides updates based on the community member’s email notification settings Group Email Invitation Member or non-member is invited via email to join a Group Group Join Request Group owner is notified that someone has requested to join their closed Group Group Membership Accepted Community member is notified that they have been accepted into a Group Group Membership Denied Person is notified of being rejected entry into a Group. Group owners can add an optional description explaining the reason the person was rejected. Group Private Message Invitation Community member is invited to join a Group. They receive a private message invitation to join and an email notification for the new private message. New Private Message Community member receives a new private message in their Inbox Private Message Sent Admin is notified when a broadcast private message is delivered Private Community Invitation Person is invited to join the community by email and receives instructions on how to register via email New Like Community member receives a like on their content New Content Mention Community member’s content is mentioned by another user Member Mention Community member is mentioned by username by another person Email Address Change Confirmation Community member attempts to change their email address (non-SSO authentication) Forgot Password Community member begins the Forgot Password flow Confirm Registration When registered, community member confirms their email address in this notification to complete the registration process (non-SSO authentication) Email Verification Required to Publish Content Community member attempts to publish content when their email address is not verified Email Address Verification Community member requests the verification email to be resent Rank Change Community member achieves a new rank Event Email Invitation Member or non-member has been invited to an event Event Private Message Invitation Member or non-member is invited to an event. They receive a private message invitation and an email notification for the new private message. New Badge Community member is granted a new badge Content Workflow notifications Notification Description Edited Saved Draft Someone edited a saved draft in a place you follow. Submitted for Review Someone submitted a draft for review in a place you follow. Submitted for Publication Someone submitted a draft for publication in a place you follow. Recalled Draft Someone recalled a draft for publication in a place you follow. Schedule for Publication Someone scheduled a draft for publication in a place you follow. Return to Author Someone returned a draft to its author in a place you follow. Return for Review Someone returned a draft for review in a place you follow. Admin-only notifications Notification Description Abuse Report Notification Admin or moderator receives a report of abusive content, private messages, or member profiles. Related topics: About NotificationsFlood controls for Aurora communities
With Khoros, there are limits on how often people are allowed to post, upload images, videos, and attachments, tag content, send private messages, and other community actions before triggering flood controls. Flood controls are in place to help combat potential spam. Note: Those with the Administrator and Moderator role are exempt from flood control restrictions; these thresholds affect only regular members. The following table lists the default flood rate settings for various actions performed by the member within a specified period of time. Actions Flood Controls Post content A member can't post more than: 5 posts in 30 seconds 15 posts in 10 minutes 50 posts in an hour Send Private Messages A member can't send more than: 5 private message in 30 seconds 15 private messages in 10 minutes 50 private messages in an hour Upload Images A member can't upload more than: 100 images at a time 5000 images per day 5000 images in the community Upload Videos A member can’t upload more than 500 videos in the community. Upload Attachments Members can’t upload more than 100 attachments per post per day. Like content A member can't give more than: 50 likes per minute 500 likes per hour 5000 likes per day Tag content A member can’t add more than: 50 tags per minute 500 tags per hour 5000 tags per day Mention people A member can’t mention more than 50 members in single post. To configure these flood controls, contact the Support team.Aurora: Ban members from the community
Each member plays a crucial role in the community's growth and is responsible to behave appropriately to create a positive space where other members feel welcome, safe, and engaged. But in some cases, members act maliciously, violate the community guidelines, or are abusive in nature. To avoid such malicious behaviors in the community, Moderators and members with appropriate permissions can ban these members and prevent them from accessing the community. Before banning a member, consider their member history, not just a single action or post. You can temporarily or permanently ban members based on the impact caused. You can ban members using their profile information (username, user ID, and email address) and IP addresses. Use IP address bans as a last resort. IP addresses tend to be dynamic and if a banned member restarts their router, they can get out of the ban and another member may receive the ban. In the community, you can ban members in several ways: Create ban rule from the Manage Users dashboard Ban members from the Content Management dashboard Ban members from the members’ profile page Ban members from the content page Create Ban rule from the Manage Users dashboard Using a ban rule, you can ban single or multiple members from the community. From the Manage Users dashboard, you can create and view the list of ban rules in the community as shown below: To create a ban rule: Sign in to the community as an Admin or Moderator. Open the Account menu and go to Manage > Users. The Banned tab on the Manage Users page is displayed. Click Create Ban Rule. Specify any of the following fields: Username: Enter a member’s username. The entry can include * and ? wildcard characters to ban all members whose usernames match all or part of the username. Example 1: If you enter the username as “Jess*,” any member whose username begins with “Jess” followed by any character will be banned. Example 2: If you enter the username as “Je?s,” the "? " replaces only the single character. The usernames like "Jess," "Jeos," and other matching usernames will be banned. User ID: Enter member’s unique User ID. Email Address: Enter member’s email address. The entry can include * and ? wildcard characters to ban members whose email addresses match all or part of the email address. Example 1: Entering “*@test.com” bans members whose email address begins with any character followed by test.com. Example 2: Entering “Je?s@test.com” bans members with email addresses like “Jess@test.com,” “Jeos@test.com,” and other matching email addresses. IP Address: Enter member’s IP address. Note that other members who use the same IP address will also be banned. Match any of the above criteria: Select this checkbox to ban a member who meets any of the criteria listed above. Otherwise, the ban is in effect only if all criteria are met. In the Ban Actions drop-down menu, select the ban Duration. The duration can be temporary or permanent as required. To set a custom duration, select Custom from the drop-down menu and set the duration. (Optional) In Ban Reasons, specify the following reasons for the ban: Internal reason for ban: Only Admins and Moderators can see this reason. They can see this reason when they edit the ban rule. Public reason for ban: Enter the reason that the banned member can see when they fail to sign in to the community. Click Ban. The impacted members are banned and signed out from the community. Ban members from the Content Management dashboard On the Content Management dashboard, you can ban members from the Spam, Abuse, and Moderation tabs using the Options menu > Ban Member. Note that you can only ban one member at a time from the Content Management dashboard. Let’s say you saw malicious content on the Abuse tab and you want to ban the member who created the content. To ban the member: Sign in to your community as an Admin or Moderator. Open the Account menu and go to Manage > Moderation. Go to the Moderation tab where you can view the list of content reported as abuse. To ban a member, open the Options menu and click Ban Member. The Ban Member window opens where the member details are auto-populated: Add information to the fields and click Ban. The Member is banned and signed out from the community. Similarly, you can ban members from the Spam and Moderation tabs. Ban members from the member profile page To ban a member from the member’s profile page: Sign in to the community as an Admin. Go to the member’s profile page by clicking the member account you want to ban on the community. Open the Options menu and click Ban Member. The Ban Member window opens where the member details are auto-populated. Specify the fields and click Ban. The Member is banned and signed out from the community. To modify ban, open the Options menu and click Edit Ban. Ban members from the content page From the content page (forum discussions, blog posts, ideas, and knowledge base articles), you can ban the member who created the content as well as members who posted replies/comments to the content. To ban an author, go to the respective post, open the Options menu, and click Ban member. To ban a member from comments or replies section, go to the comment or reply posted by the member, open the Options menu, and click Ban Member.Aurora: 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.Aurora: Create a blog post
Community members can create posts in blog boards they have permission to access. When authoring posts, you have the option to publish immediately or save your progress and edit or publish at a later time. Published blog posts are available immediately on the community. When other members find and read this content, they can like or comment on it. Members with appropriate permissions can view the author's profile, and add more Tags. As an author, you can always come back and edit this content later to add more info or make any corrections. https://www.iorad.com/player/2053665/intermitted-save---blogs Notes: You can use markdown syntaxes while writing the content instead of formatting the text using toolbar options. Also, you can use other keyboard shortcuts to work quickly and efficiently. Learn more about keyboard shortcuts. While creating a blog post, the content is auto-saved. Upon reloading the page, the content is auto-recovered and you can continue to edit. Admins and members who started the post or have edit access to the post can add or remove tags. Learn more about tags. By default, members who comment on an article automatically follow the post. Permissions Permission Purpose Additional permissions required Start new posts To create your own blog posts. Content > Start discussions and new content View draft posts View drafts of blog posts Managing published posts Members with elevated permissions (like admins and moderators) can perform a variety of content management tasks on published blog posts. These tasks include: Move the post to another location on the community View the revision history of a blog post Edit and restore older versions of a post Delete the blog post Reject Report Content Block further edits to the blog post Block comments Most of these tasks are available from the Options menu: Note: If you don’t see any of these menu options, you do not have the required permissions to complete these tasks. Related topics: Create a Blog board Commenting on blogs Edit posts Publish posts Report inappropriate Follow Content TagsAbout 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 descriptionsAbout Following in Aurora
Following places, content, groups, comments, replies, and tags enables you to receive updates regarding those areas or features. For more information about how these types of follows function, review the sections below. Note: If you are the author of a particular discussion, blog post, article, idea, or event, you will automatically receive updates for that content. Additionally, if you comment on a particular piece of content, you will automatically receive updates for that content. When you receive a notification, a dot appears over the Notifications bell icon in the header anywhere in the community. Click this icon to see a list of your notifications. See About Notifications. You can also choose to receive email notifications. See About Email Notifications. Follow Places and Content Follow Boards and Content To follow a board (forum, knowledge base, blog, ideas, or events) or a specific discussion, blog post, article, idea, or event, go to that page and click Follow (bell icon) at the top right of your screen. A confirmation message is displayed. Follow a Category Go to the category you want to follow and click Follow (bell icon). On the Follow window, select one of the following: All Boards in this Category These Boards in this Category If you selected These Boards in this Category, you can select specific boards to follow. Note: If you selected All Boards in this Category, you are subscribed to any boards that are added to the category later. Click Follow. A confirmation message is displayed. Follow a Group To follow a group, go to that page and click Follow (bell icon) at the top right of your screen. A confirmation message is displayed. Follow a Comment or Reply To follow a comment or reply on an article, open the Options menu and then click Follow Comment or Follow Reply, respectively. A confirmation message is displayed. Follow a Tag Following tags enables you to follow specific keywords around the community or a particular board. Any time a piece of content is tagged with a tag you follow, you receive a notification. For example, maybe you want to follow all content tagged with “concerts.” Any time someone creates content and tags it with the “concerts” tag, based on your settings, you receive a notification regarding this content in the community or board. You can follow tags at both the community level and at lower levels based on the scope of the tag page you’re on. To follow a tag: On a piece of content with a tag you want to follow, click the tag. On that tag’s page, click Follow (bell icon). Note: Use the breadcrumbs to scope to the desired area by clicking its linked name before you click Follow. On the Follow window, select between Follow in this Board and Follow across the Community. Click Follow. A confirmation message is displayed. Unfollowing After you’ve chosen to follow boards, content, or categories, you can manage the items you follow in a number of ways: Manage Follow and Notification preferences for your account Unfollow Places and Content Unfollow a Comment or Reply Unfollow a Tag Unfollow Places and Content On the page for any category, group, board, or piece of content, click Unfollow (the icon is now a bell with a checkmark on it to indicate that you’re already following that place or content). For categories, you must either select to Unfollow the entire category or deselect checkboxes below These Boards in this Category to unfollow specific boards in that category. For groups, boards, and content, you do not need to perform additional actions to unfollow. In both cases, a confirmation message is displayed. Unfollow a Comment or Reply To unfollow a comment or reply on an article, open the Options menu and then click Unfollow Comment or Unfollow Reply, respectively. A confirmation message is displayed. Unfollow a Tag On the page for any tag you’re following, click Unfollow (the icon is a bell with a checkmark on it to indicate that you’re following that tag). If you want to unfollow the tag across the entire community, click the highest level link (e.g., “Tag: concerts”) after the community name in the breadcrumbs before unfollowing—otherwise, it will be scoped to a specific place. Once you’ve unfollowed, a confirmation message is displayed. Related topics: Manage Follow and Notification preferences for your account Configure Follow settings for the communityAurora: 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 community
