About Aurora content filters
Communities are meant to be a safe space where members should feel welcomed and engaged. Sometimes, members post objectionable content that may offend other members and negatively impact the community’s overall health. Objectionable content can include inappropriate language or any other terms you might not want to see in the community. Aurora offers content filters as part of its moderation tools to prevent objectionable content from appearing in posts, replies, tags, private messages, profile information, and member registration. When members use inappropriate words across the community, content filters identify them and prevent the content from being published or replacing the words with pre-defined replacement terms. In other cases, content filters just record the objectionable content posted across the community without taking any action. Content filters can also be used to ensure that the correct words are used across the community to improve content consistency. For example, you could create a content filter to replace old product names with the correct product name. Aurora includes several default filters that can be triggered when someone registers, posts, adds a tag, sends private messages, or updates their profile information. Default Filter Applies to Filter action Smut Posts and replies Prevents objectionable language from appearing in posts. Replaces offensive terms with neutral or slightly humorous ones, if configured to do so. Remember, you don’t want to prevent members from posting messages; you just want to keep the language clean. You may want to have your moderators keep an eye out for members who repeatedly use filtered language. Keyword Posts and replies Manages specific words or phrases. Content for this filter may include product and company names—both your own and those of competitors. When filtered keywords are used in content, moderators are notified. Optionally, the terms are replaced with more appropriate or the correct term. Login User signups (Registration page) Prevents people from registering to the community with an inappropriate username or profile info (system default action). Note: The Login filter is not applied if you are using an SSO implementation that passes the person’s username to the community. You must have a system on your side to deal with this situation. Tag Tags added in posts and replies Prevents members from tagging posts with objectionable words. Replaces with an alternate tag if configured to do so. You can add terms to these default filters or edit default filters as needed. You can also add new filters to perform these actions when the filter terms are identified in the community: Do not allow: Prevents members from posting content or replies, registering to the community, adding tags, updating profile information, and sending private messages till the filter term is removed. This more heavy-handed approach runs the risk of either challenging members to find a way to defeat it or alienating them. When filter term is identified, the following error message is displayed: Replace term: Replaces the offensive term with another term. This is the most common way of handling smut filter infractions. You can configure what term to replace words that match this filter in the Replacement term field. When the filter term is identified, it is replaced with the configured term after you post the content. Check inline HTML and do not allow: Prevents the members from posting anything that contains a filtered term after ignoring inline HTML. For example, the term “crap” written in inline html format, “c<b>r</b>a<br>p” in any new post is identified as the filter term after ignoring the inline html. Take no action: Does not take any action on the filtered terms that appear across the community, but records in Content Filters dashboard to notify moderators about these terms used across the community. Tip: Replacement terms are often a better management strategy versus preventing members from posting, as some people might take it as a personal challenge and invest tremendous effort in attempting to circumvent your filters. Another way these members may try to circumvent your filters is by using variations of banned words. For that reason, you may want to plan ahead for possible misspellings or other variations when creating your content filters. Note: Content filters are not case sensitive. For example, to filter for “Test,” “test,” and “TEST,” you need to enter only the term “test” while creating the filter.Aurora: 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. 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 SSOBypass flood control
If you want to allow trusted members to publish content without being blocked by flood limits, grant the Bypass flood control permission. To deny or grant this permission for a role Sign in to the community as an Admin. Go to Settings > Users > Roles and Permissions > Moderation. Select Grant or Deny for the Bypass flood control permission. If this permission is denied for any role and a member with that role exceeds the flood control limit while attempting to publish content, an error message appears at the bottom of the page and the content is not published.Bypass content filters
If you want to allow trusted members to publish content without being blocked by any content filters, grant the Bypass content filters permission. To deny or grant this permission for a role Sign in to the community as an Admin. Go to Settings > Users > Roles and Permissions > Moderation. Select Grant or Deny for the Bypass content filters permission. If this permission is denied for any role and a member with that role attempts to publish content containing any words listed under Content Filters, they receive an error message at the bottom of the page. For example, below is a screenshot of the error message when a user without this permission cannot publish their content because the word “cannibalism” is listed under Content Filters.About Aurora Communities spam management
Khoros Community spam management tools run in the background, where each new message is logged and tested for spam. Additionally, our system learns about your site content as it monitors all your boards and forums, enabling it to improve its content filtering over time.
Aurora Product Coaching Session: Spam Management Best Practise
Khoros Communities platform offers several settings and features that allow you to mitigate Spam in your community. Join our Spam Management Best Practice coaching session to identify, filter and deal with spam effectively. Our coaching session will guide you through the practical tips and techniques to help combat spam and help maintain the hygiene of your community. Topics covered in the coaching session Overview of Aurora spam settings and functionality Manage Content dashboard related to spam management and its features Using roles and ranks to configure permissions to check spammers Content Filters Best practice tips Notes - Admin permissions are required to conduct the call. 👉Click here to Sign Up Related Resources Enable Spam Management Community Spam Management Review Posts Captured as Spam Khoros Academy: Communities Moderation Essentials Khoros Academy Instructor Led Training: Spam Management for Communities AuroraAurora: 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. Related topics: About Khoros Aurora Single Sign-On (SSO) Khoros Aurora SSO auto-sign in Configure SSO settings for the communityAurora OpenID Connect/OAuth 2.0 setting descriptions
This article describes all the OIDC- and OAuth2.0-related settings within Settings > System > Account > OIDC/OAuth Providers. If OIDC/OAuth Providers and its subsections are not displayed in the panel on the left, contact Khoros Support and request that the OIDC/OAuth feature be enabled. Learn more about the OIDC/OAuth 2.0 feature. Provider Information Name: Desired name to label this provider within the settings. ID: Desired ID to give to this provider. This ID is used within the Sign-in URL and Registration URL that are defined in Settings > System > Account > Single Sign-On (SSO). Client ID: The Client Identifier used to validate against the authorization server. Client Secret: The Client Secret used to validate against the authorization server. Authorization URL: The authorization endpoint which will return either the authorization code (Authorization code flow) or the ID token (implicit flow). Response type: Community only supports the Authorization Code flow; code is the default value for Authorization code flow. Scope: Defines what access privileges are being requested. To use OpenID Connect requests, openid value must be used. If supported, other scope values may be profile, email address, address, and/or phone. The scope defined here will determine which Claims are returned from either the ID Token or User Info endpoint. Multiple values input here must be separated by a comma. Add Static Parameters: Add any additional parameters that should be sent with the authorization URL during sign-in by clicking Add Parameter. You must enter the Key and Value. This can be used for passing optional parameters such as max_age, claims, etc. Persist parameters: When enabled, any query string parameters passed to the Khoros OIDC sign-in endpoint will be passed through to the Authorization URL upon sign-in. Parameters to be persisted can be added to the Registration page and Sign-in page URLs defined in general SSO settings for the community. Enable PKCE: Turn on this option to enable Proof Key Code Exchange for the authorization code flow. The OpenID Provider must also be configured to support this flow. Token URL: The token endpoint which will return the ID token. Client auth method: Authentication method to the token endpoint. Only two methods are supported, with the option to disable only if PKCE is being used. client_secret_base: Uses HTTP basic authentication. client_secret_post: Includes the client credentials in the request body. none: For security purposes, this should be chosen only if PKCE is used. Static Parameter (optional): Any static parameters that are used to request a token can be defined here. Header parameters (optional) Claim mapping (ssoid required): Any Claims returned from the token endpoint can be mapped here to an Aurora community profile attribute. JWT Options Note: The following options apply only to OIDC setups. Audience Override: (OIDC only) Audience is used in JWT validation. By default, JWT validation checks if the Audience (aud) claim in the JWT matches the client ID. If another aud claim is expected, enter it here. Issuer: (OIDC only) Should be set to the OpenID provider. Typically, it is the same as the Token endpoint. JWKS URI: (OIDC only) This URL contains the verification keys that are used in JWT validation. Disable JWT validation (for testing purposes only): (OIDC only) OpenID Connect flow must use JWT Validation according to spec. User Info (Optional) URL: URL of user info endpoint that is used to retrieve user information. The user info endpoint uses Bearer Authentication, if a URL is provided, then the token endpoint MUST return an Access Token. User attributes can also be obtained directly from the id_token where available. Use POST request: By default, the user info endpoint is called with a HTTP GET. Turn on this option if HTTP POST should be used instead. Static Parameters: Any static parameters that are used for the user info endpoint can be defined here. Header Parameters: Add any additional parameters that should be sent with the header during sign-in. Add Claim Mapping: Any claims returned from the user info endpoint can be mapped here to a Community profile attribute. These are used to specify key value pairs of claim values to be stored in the user's profile. The claims mapping is applied to the /token call response itself unless the id_token property is present, in which case the mapping is applied to that JSON body. Be aware of the following considerations when mapping user claims to community user attributes: ssoid: You must provide a mapping for this user attribute. The value of the user must be both unique and immutable. Additionally, the value is case sensitive. email: The value for the user must be unique. If you are unable to supply a user’s email address via the login flow, open a Support ticket to ask about having the user SSO registration page enabled to allow the user to be prompted to set their email address on first login. login: This must meet character requirements. roles.grant or roles.remove: If you supply mapping for these attributes, the value mapped must be a comma-separated list of role names, and those roles must already exist in the community. profile.url_icon: The user’s Community profile image can be set to a remotely hosted resource so long as it is accessible to the Community. Note: For other common profile fields, refer to User profile data in the Khoros Developer Docs. Logout (Optional) RP Initiated Read more information on OpenID Connect Relying Party (RP) logout. RP URL: The URL that is called when using Khoros /sso_logout_redirect endpoint. A back-channel request will be made to this logout URL passing the user’s access token. This URL is expected to sign out the user from the provider and functions as a single logout. Authorization method: Authorization method used when calling the logout endpoint. Basic uses the client ID and client secret in the Authorization Basic header. Bearer uses the user’s access token in the Authorization Bearer header. With None, no Authorization header is passed with the sign-out request. Token method: Optional field and not typically needed if the authorization method is set to Bearer. Selecting Form URL Encoded Body passes the user’s access token as application/x-www-form-urlencoded. JSON Body passes the user’s access token as application/json. RP param name: When the token method is set to Form URL Encoded Body or JSON Body, use this setting to specify the name of the parameter to pass. Defaults to token. RP Params passthrough: When enabled, any query-string parameters passed to the Khoros OIDC logout endpoint are passed through to the Logout URL during sign-out. Static Parameters: Additional parameters that should be passed to the Logout URL. OP Initiated OP enabled: When this setting is turned on, the logout endpoint can be used by the OpenID Provider (OP) initiated logout flows. OP allow iframe: When this setting is turned on, it allows the logout endpoint to be called via iframe and allows use with front-channel logout flows. OP URL: Users that browse to the logout endpoint are redirected to the specified post sign-out redirect URL after being signed out. By default, users are redirected to the community front page. Note: For private communities, this may result in immediately redirecting the user to sign in again. If you have a private community, you may want to specify an external URL (for example, on your .com). OP iframe redirect url: Use this to specify which URLs may place the logout endpoint in an iframe. In practice, this sets the Content Security Policy response header frame ancestor's value. Frontend Logout Frontend logout URL: If the frontend logout URL field is configured, the user will be sent to this location with their id_token_hint attached upon logout so that they may be cleanly logged out of the IDP. This also makes it possible to overwrite the post_logout_redirect_url if needed. Frontend logout params: Enter any additional parameters that should be sent with the frontend logout URL during sign-out. This can also be used for passing additional parameters. Alternate name for post_logout_redirect_uri: This value overrides the default post_logout_redirect_uri query parameter name. Advanced Redirect URI Override: This setting is primarily for testing purposes and typically not used in production environments. If a different redirect URI needs to be passed to the OP, it can be defined here. Note: The authorization code may be accepted only at the Community generated callback URL. Related topics: About Aurora OIDC/OAuth2.0 SSOAurora: Configure SAML for the community
As an Aurora community admin, you can configure authentication for your community and integrate with your SAML IdP. To configure your SAML settings, go to Admin > Settings > System > Account. If SAML and its subsections are not displayed in the panel on the left, contact Khoros Support and request that the SAML feature be enabled. Learn more about Khoros SAML here. For more details regarding individual SAML settings, see About SAML settings. Set up basic SAML Configure your identity provider. Retrieve Community Service Provider Metadata XML: /t5/s/<communityID>/auth/saml/metadata Update the external Identity Provider configuration using values provided by Community SP metadata XML. Go to Admin > Settings > System > Account. Scroll down to the SAML section, and below SAML Basics, ensure that Enable SSL Authentication is turned on if the SAML setup requires Secure-Sockets Layer (SSL) connection. In the IdP Metadata section, in the Metadata XML area, click Edit to paste your IdP metadata XML, provided by your IdP. In the Assertion to Profile Mapping section, enter the name of the attribute corresponding to the field you want to map from your SAML assertion (see Assertion to profile mapping in About SAML settings). A SAML assertion is the XML document that contains the user authorization details and is case sensitive. The identity provider sends this XML to the service provider. With the exception of the SSOID value, user settings can be gathered either directly from assertion attributes from your identity provider or else can be captured on the SSO User Registration form. Note: Adjustments to the SSO registration form currently require manual configuration by Khoros. When you have finished your SAML configuration and are ready to test, in the Single Sign On (SSO) section, turn on Use Khoros single sign-on (SSO). Set up SP-initiated SAML To set up SP-initiated SAML flow, you must also set up the basic SAML flow. Note: The Registration page, Sign-in page, and Sign-out page URLs (in the Single Sign On (SSO) section) must be preceded by your community ID. Contact Khoros Support and request the Community ID. Go to Admin > Settings > System > Account. In the Single Sign On (SSO) section, below SSO URLs, click Edit. In the Registration page field, enter the URL of the default page to which you want to redirect the users when they click the registration link to register to the community. If you use the (default) SAML POST binding for AuthN requests, then enter /t5/s/<communityID>/auth/saml/doauth/post If you use the SAML REDIRECT binding for AuthN requests, then enter /t5/s//<communityID>/auth/saml/doauth/redirect In the Sign-in page field, enter the URL of the default page to which you want to redirect members when they sign in to the community. If you use the (default) SAML POST binding for AuthN requests, enter /<communityID>/auth/saml/doauth/post If you use the SAML REDIRECT binding for AuthN requests, enter /<communityID>/auth/saml/doauth/redirect In the Sign-out page field, enter the URL of the default page to which you want to redirect members when they sign out of the community. Click Save. Turn on Use Khoros single sign-on (SSO). Set up IdP-initiated SAML To set up IdP-initiated SAML flow, you must also set up the basic SAML flow. If the SAML Request for community sign-in should originate from your Identity Provider rather than from the community itself, a slightly different configuration will be required. Go to Admin > Settings > System > Account. In the Single Sign On (SSO) section, below SSO URLs, click Edit. In the Registration page and Sign-in page fields, enter the URLs for your Identity Provider’s SAML sign-in/registration services. This is in contrast to SP-initiated configuration, which would specify community-specific SAML authentication services. In the Sign-out page field, enter the URL of the default page to which you want to redirect the members when they sign out of the community. Click Save. When you have finished your SAML configuration and are ready to test, in the Single Sign On (SSO) section, turn on Use Khoros single sign-on (SSO). Note: The query parameter that carries the community resource URL initially requested by the user when they sign in must be persisted with the SAML Response sent from your Identity Provider. This is to ensure the user lands on the community page where they signed in. This query parameter name is configurable using the Return Value Parameter Name setting. Ensure that the same parameter name used when the user is directed to your IdP is also sent with the SAML Response.
