About Khoros Aurora Single Sign-On (SSO)
Khoros Single Sign-on (SSO) enables you to integrate your sign-in and registration system with your Khoros community member system. To create a seamless sign-in experience for community members, the Khoros SSO solution enables your user system to: Create a new member account in your community Sign in a member to the Khoros system Change a member's personal profile parameters in the Khoros system by assigning a role Change a member's permission levels in the Khoros system Members sign in as usual through your main site. After they sign in, they are forwarded to the Khoros site and are automatically signed in or registered in the Khoros system. To integrate with Khoros SSO, the client system must: Be able to create Khoros SSO tokens from its user system Have the Khoros SSO libraries installed Have a client-specific C encryption key installed SSO workflow diagrams Khoros supports cookie-based and parameter-based workflows. Cookie-based Khoros SSO Parameter-based Khoros SSO SSO Sign-Out Flow The flowchart below shows where members are directed upon sign-out. Khoros (Lithium) SSO libraries Khoros issues the Khoros SSO libraries (Java, .NET, or PHP) and a unique encryption key for each deployment. Information for all three versions is provided in the attached SSO Guide. Additionally, you can refer to the attached flowchart for a diagram that explains how SSO works with the Khoros Platform. Note: When using the .NET library, you must have the .NET Framework, not just .NET Core available for all requests to operate properly. Related topics: Khoros Aurora auto-sign in Configure SSO 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. 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 SSOAbout 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. After the provider has been created, you must define the registration and sign-in URLs so the Community knows where to direct users when they sign in. To define the registration and sign-in URLs, see Configure SSO settings for the community. 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. Related topics: Aurora OpenID Connect/OAuth2.0 setting descriptionsAurora: 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. 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 If the SP metadata is inaccessible, contact Khoros Support and request that the SAML feature be enabled. Update the external Identity Provider configuration using values provided by Community SP metadata XML. Go toAdmin > 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.Aurora: MultiAuth 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) Note: Contact Support to enable this feature in your community. After the feature is enabled, you can see the Sign-In Display option under Settings > Systems > ACCOUNT > Sign-in. 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 will be displayed when users are 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 the 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 communityAbout Aurora SAML settings
As an Aurora community admin, you can configure authentication for your community and integrate with your SAML IdP. To follow step-by-step instructions, see Configure SAML for the Aurora community. The following article describes each SAML setting. Basic SAML settings Setting Description Enable SSL authentication Turn on this option if the SAML setup requires an SSL connection and uses https for endpoint calls. SSO ID regex Click Edit to enter a regular expression to extract the SSO as a substring of an attribute. By default, the entire attribute value is used as the SSO ID. If nothing is specified, the entire value is used and no additional logic is applied. IdP settings Your identity provider must provide you the IdP metadata XML. This should contain the IdP certificate, the entity ID, the sign-in bindings as well as sign-out binding if used. To configure more than one identity provider, contact Khoros Support. Assertion to profile mapping Assertion mapping Description SSO ID Enter the SAML Response assertion attribute name that should be mapped to the Community user SSO ID. For example, if the attribute name for the SSO ID is NameID, enter NameID in this field. This mapping is required. Community login Enter the attribute name for the user’s display name in the community. This mapping is required unless the value is gathered on the Aurora Community user registration page. Email address Enter the attribute name for the user’s email address. This mapping is required unless the value is gathered on the Community user registration page. First name Enter the attribute name for the user’s first name. Last name Enter the attribute name for the user’s surname. Location Enter the attribute name for the user's location. This maps to the location setting that you specify in the community member’s profile page. Time zone Enter the attribute name for the user's time zone. This maps to the time zone setting that you specify in the community member’s profile. Language Enter the attribute name for the user's language. This maps to the language setting that you specify in the community member’s profile. Roles to add attribute Enter the attribute name holding a comma-separated list of existing community Role names (any roles that do not exist in the community are ignored). Role names are case sensitive. The user is added to the matched roles. Roles to remove attribute Enter the attribute name holding a comma-separated list of existing community role names. Role names are case sensitive. The user is removed from the matched roles. Any roles that do not exist in the community are ignored. Dynamic assertion mapping Enter any custom Aurora community user settings that are not listed in this tab. This is a newline separated, key-value pair: Community Setting name = SAML Response attribute name. Example: profile.langcode=preferredLanguage Do not set login value from IdP Turn on this option to stop the SSO parameters from being populated with the login value. Use this if you want to track the related attribute name via configuration but you have enabled the user SSO registration page for the user and are collecting the login name from the registration page instead of passing it from the SSO. SP metadata The SP Metadata URL is provided here. Turn on Accept all audiences if you want to bypass the audience URL verification. This option is turned off by default. Sign-in settings Setting Description Enable login querystring override Turn on this option when you want to append more login endpoint parameters that are not specified in the IdP metadata. When enabled, the key and value defined in the login querystring key and value are appended to the HTTP POST binding login flow. Login querystring parameter Click Edit to enter the login querystring value that is most often passed and appended to the IdP for an SP-initiated AuthN request. Encode login value Turn on this option to HTML-encode the login querystring value. Enable register querystring override Turn on this option to pass additional parameters other than the ones specified in the IdP metadata for the member registration flow. Register querystring parameter If you turn on the Enable register querystring override setting, click Edit to enter the URL query parameter that must be passed when initializing the SAML post binding (not the redirect binding) login request. Encode register value Turn on this option to HTML-encode the register querystring value. Sign-out settings Setting Description Request signed Turn on this option if you want all the SLO (single logout) requests signed. Response signed Turn on this option if you want all the SLO (single logout) responses signed. Redirect URL Click Edit to enter the URL of the page to which you want to redirect members after they sign out. Advanced settings Setting Description Skip signature check Do not turn on this option in a community’s production environment. Turn it on only while testing and you want to skip the response and assertion signature check. Timeouts Click Edit to adjust the following timeouts: Response expiration In seconds, specify how long the SAML Response remains valid from the time it is deemed valid. The default is 60. Assertion expiration In seconds, specify the maximum time an assertion is usable after it is created. The default is 3000. Authentication expiration In seconds, specify the maximum time a member’s authentication is valid. The default is 7200. Response valid before In seconds, specify the maximum time the message is deemed valid before response creation. The default is 10. Assertion valid before In seconds, specify the maximum time the assertion is valid after generation. The default is 10. Authentication valid before In seconds, specify the maximum time allowed before the member’s authentication. The default is 10. Don't verify subject element on or after (in ms) In milliseconds, specify the maximum time that the subject element in assertion is valid. Only verify response signature Turn on this option to skip the assertion signature check in cases where the IdP is signing the response and not the assertion. Skip assertion IP check Turn on this option if you have specified an IP address in the SAML assertion and want to bypass the IP address check. If you do not turn on this option, the IP address of the request and the IP address in the assertion are compared. Skip assertion consumer service check Turn on this option if you want to bypass the check that determines whether the community is the intended recipient of the assertion. Allowed audiences Click Edit to enter the list of comma-separated hostnames if you have different hostnames for your community and different members sign in to your community through different hostnames. URL encode return value parameter name Turn on this option to encode the return value parameter name added in the requests to avoid misinterpretation of referrers that contain URL-sensitive characters. Skip instance AuthN check Turn on this option to skip the time check validation performed on the AuthnInstant attribute of the AuthnStatement within the assertion. This is a workaround for customers that use the AuthnInstant to indicate when the member authenticated to their system (per the SAML specifications), which could be days, weeks, or even months in the past. This does not impact other time validations performed for the SAML Response and the assertion. This will likely be required for any customer using ADFS as an IdP. Related topics: About Security Assertion Markup Language (SAML) Single Sign-On (SSO) in Aurora Configure SAML for the Aurora 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. 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 SSOKhoros Aurora SSO auto-sign in
The Khoros Single Sign-On feature enables any client user system to integrate its sign-in and registration system with Khoros Community. This solution creates a seamless sign-in experience for community members. Members sign in as usual through the main client site. After signing in, they are forwarded to the community site and are automatically signed in or registered on the Khoros system. While auto-login works for local authentication as well as any supported SSO mechanism, the steps describe the process for the Khoros SSO sign-in flow: Member signs in to your system If the member is already in the system, go to step 2. If the member is new, require them to register and create an account through the normal method for your system. It is recommended that you capture a uniqueID and email address. Pass the following parameters to LithiumSSOClient class to generate the SSO token: uniqueID parameter login (display name) parameter email parameter The token (cookie) is generated and the member is authenticated in the community. When the member comes to the community, Khoros verifies the token (to make sure it was generated by your system) and lets the member in. Note: Auto sign-in works only if the user has accepted to set cookies. Notes: If your system does not capture both an ID and an email, the uniqueID can be the same as the email address as long as all users are guaranteed to have a unique email address. If using an email address for uniqueID, pass the email address twice for both uniqueID and email parameters. If your system is not currently capturing a display name or profile name for the community user, Khoros can configure your community to direct members to a profile setup page where the member will create a username (display name). However, you still need to pass any character (for example, a single space) in the login parameter. Khoros will then ignore this value since the member will be asked to choose a login. Ask your Customer Success Manager to set this up for you. Some communities choose to implement “bounce” SSO as well, where Khoros configures a “bounce URL” to redirect a browser to the first time it comes to a Khoros site. That URL is hosted by the customer and is used to check if a member is logged in and to redirect back to Khoros with an SSO cookie (or SSO token in a query parameter). This adds a seamless login experience for cases where a member is already logged in to a customer site and goes straight to the community. Use the flowchart below to discover what happens when you have auto sign-in enabled in your community. This flowchart begins with a member accessing a community page after their session has expired. The chart ends with the member being logged in or directing you to the SSO flowchart named SSO_login.pdf, which you can find linked at the bottom of theAbout Khoros Aurora Single Sign On (SSO) article on Atlas. Relatedtopics: About Khoros Aurora Single Sign-On (SSO) Configure SSO settings for the community MultiAuth SSOAbout Aurora Security Assertion Markup Language (SAML) Single Sign-On (SSO)
Single-Sign On (SSO) eliminates the need for users to provide their login credentials each time they sign in to different applications and services. With SSO, users can sign in once, and those same credentials can be reused to sign in to other applications or services. SAML enables Single-Sign On. Learn more about Khoros Single Sign-On. SAML SSO Supported SAML 2.0 profiles Supported flows Existing customers who want to upgrade to Aurora and port their existing SAML configuration may want to contact their Customer Success Manager or Account Executive. This process can be involved, and a Professional Services (PS) engagement can ensure a successful reconfiguration and help address any existing customizations such as user authentication workflows, custom user profile fields, and other customizations or integrations relying on user data. About Khoros SAML SSO Let’s begin by defining some terms in the context of the Khoros Aurora platform: IdP (Identity Provider): This is your SSO server. IdP is a server or service that provides the end-user identity authentication and SAML assertion. The IdP is owned and managed by you (the customer). SP (Service Provider): This is your Khoros community. SP is a software/service platform that consumes/processes the assertions SAML provides. Security Assertion Markup Language (SAML) is an OASIS standard for passing single sign-on (SSO) authentication data from an identity provider to a service provider. This XML-based protocol uses security tokens containing assertions to pass information about an end user between the SAML Identity Provider (IdP) and SAML Service Provider (SP). Here's an overview of the SAML SSO workflow: SAML implements a secure method of passing user authentications and authorizations between the identity provider and service providers—in our case, your community. When a user signs in to a SAML-enabled community, the community (the SP) requests authorization from the appropriate identity provider. The identity provider authenticates the community member’s credentials, then returns the authorization for the member to the community, and the member is signed in to the community. Supported SAML 2.0 profiles We support the following SSO profiles used to define the assertions, protocols, and bindings that support your integration: Web Browser SSO Profile, involving an identity provider (IdP), a service provider (SP), and a user employing an HTTP user agent (usually a web browser). Single Logout Profile in conjunction with the HTTP Redirect binding (no backchannel communication) Khoros supports HTTP POST and HTTP Redirect SAML 2.0 bindings, which map SAML protocols to other messaging and communication protocols. Supported flows Khoros supports the following two flows for SAML: SP-initiated SAML IdP-initiated SAML Read on to learn how community admins can configure SAML SSO for their community by themselves. Related topics: Configure SAML for the Aurora community About SAML settings
