Aurora: Multi-Auth SSO
Communities require diverse authentication methods to accommodate varying member segments like employees, customers, etc. Admins can offer multiple sign-in options simultaneously, providing enhanced flexibility. These options include: Khoros SSO Up to three IDPs for SAML More than three IDPs for OIDC/OAuth2 (OIDC can be configured via admin only) To edit these settings, go to Settings > Systems > ACCOUNT > Sign-in. If Sign-In Display is not displayed, contact Khoros Support and request that the Multi-Auth feature be enabled. Edit the Sign-In Display option to configure the sign-in options you want to provide your members and how you want to display the sign-in options. Below is an example on the list of sign-in options you can configure. From here, you can: View all available sign-in options for your community. Add a welcome note that is displayed to users on the sign-in page. Turn on or off the sign-in options you prefer. Edit the labels of the sign-in buttons. Rearrange the order in which the sign-in options appear on sign-in pages. Choose to display the sign-in options as buttons for member sign-in. If you select the Display as sign-in button option, members see a sign-in button. If you de-select this option, members see a sign-in form instead. Enable SSO When you have finished your OAuth or OIDC configuration and you are ready to test, in the Single Sign On (SSO) section, turn on Use Khoros single sign-on (SSO). For more information, refer to Configure SSO settings for the community. Related topics: About Khoros Aurora Single Sign-On (SSO) Khoros Aurora SSO auto-sign in Configure SSO settings for the communityAbout 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 communityAbout 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 descriptions
