Plan single sign-on and learner identity

Give people a familiar route into Honen with the identity system your organization already uses. Choose the sign-in flow, decide how new learners join, and test the experience before rollout.

Choose a sign-in path

Open Organization → Integrations → Identity & SSO in the intended team workspace. Administrators need Manage integrations and Manage identity providers permissions to configure the connection. Agree the provider-side application and rollout audience with your identity administrator.

Plan for a SAML-based identity environment

Many organizations use one identity provider for both SAML and OpenID Connect applications. For Honen, have your identity administrator configure an OIDC confidential web application in that provider and use the Honen callback URL. The OIDC guide includes the provider choices and exact connection fields.

If your organization's requirements specify SAML assertions or SAML-only application registration, agree the integration approach with the Honen team before rollout. Share the provider, intended audience, provisioning needs, and required application protocol so the setup can be planned precisely.

Choose how people join

• JIT provisioning on: a new email can create a real Honen account and join the configured workspace during sign-in.
• JIT provisioning off: arrange the person's Honen account and workspace membership before the first sign-in.
• Default member role: choose Member for learners or Instructor for people who need the instructor role. Review your workspace's role permissions separately.

For planned cohorts, create the group, add the right members, and prepare assignments. Identity, group membership, and assignment requirements are distinct parts of the rollout.

Share your workspace login address

Give learners your workspace's Honen subdomain, such as https://northstar.honen.com. Use this address in welcome messages, bookmarks, and your organization website. The page identifies the workspace and shows its configured sign-in methods. When you configure Microsoft Entra SSO, learners can select that method on the same page.

Paid activation and workspace creation by the Honen account team request a subdomain based on the workspace name. Member routing starts after the domain is active. Existing active primary domains remain in use.

1. Open Organization → Settings in the intended workspace.
2. Find the workspace's subdomain in the domain settings.
3. Confirm its active status and primary-domain selection.
4. Enable Route members to your domain if needed.
5. Open the address in a private browser window.
6. Complete a test sign-in before sharing the address.

Your Honen account team manages custom domains that your organization owns, such as learn.northstar.example. Contact that team for custom-domain setup or changes.

An email entered on the normal Honen login can also lead to this workspace page. Configure the SSO connection's email domains and required domain sign-in first. The connection and active primary domain must belong to the same workspace. Without required domain sign-in, the normal login keeps its existing behavior.

Use one account across trusted identity providers

Use email matching when your organization controls the email addresses supplied by its providers. A workspace administrator chooses which connections Honen trusts. Use the same email for each person in your LMS, roster, and SSO directory. Give each person a distinct email. Selected providers identify the same member whenever they supply that email.

1. Open the intended workspace's LMS or Identity & SSO integration page.
2. Find One account across identity providers.
3. Enable Link sign-ins from trusted providers.
4. Select the LMS, roster sync, and SSO sources your organization trusts.
5. Wait for the saved confirmation after each change.
6. Test an LMS launch and an SSO sign-in using the same person's email.
7. Confirm the same member, assigned courses, groups, and progress in both sessions.

Select Microsoft Entra SSO when you plan to add Entra later. This selection applies to Entra connections in this workspace after you configure and enable them. It does not install Microsoft SSO or create a provider application. Each other connection has its own selection. A workspace administrator must configure or change connections selected for account matching.

A first sign-in from a selected provider uses the existing workspace member with the matching email. The learner does not need another account-connection step for that match. The member's original signup method does not change this workspace policy. Returning sign-ins use the saved provider identity, so a later email change does not switch accounts.

With JIT provisioning enabled, a new person can receive an account in this workspace during sign-in. An account in another organization can use the same contact email and remains separate. Turning matching off stops new automatic matches; it does not disconnect identities already linked.

Roster sync keeps each provider's person identifier and group placements. Selected roster sources can match the same member by email when SSO arrives. Moodle launches can also claim the roster entry by the stable Moodle user ID from the same site.

Check existing duplicate accounts before rollout

This setting links sign-in methods to one member. It does not combine two accounts' saved work or delete historical accounts. If two current workspace members use the same email, ask your Honen account team to review them. Use each person's provider ID and course history to identify the correct member. Do not delete accounts with saved progress to resolve a sign-in issue.

Without selected-source trust, an existing-account match can require the owner to sign in and confirm the connection. Test this flow if your rollout keeps automatic matching off.

Choose the session scope

The usual SSO session is scoped to the connected workspace. This gives learners a focused entry point for that organization's learning.

Moving between Honen and a workspace website preserves the original sign-in provider and its workspace or course restrictions. Website handoffs recheck the source session, so expired or revoked sessions require a fresh sign-in.

Use Allow account-wide session requests only when your rollout needs a broader account experience. An account-wide session requires the client to request it, the workspace setting to allow it, and the user to approve that identity. Keep the ordinary workspace scope for a dedicated workforce or customer-learning launch.

Manage the connection over time

Assign an owner for provider configuration, credentials, and test accounts. Keep a record of the issuer, intended workspace, application owner, role choice, and first successful learner test. Rotate credentials using the connection's controls and retest the launch.

Use the connection's enabled state to control new sign-ins. When retiring a connection, plan account access and session revocation as part of the change: disabling new sign-ins and ending existing sessions are separate actions.

Continue with OIDC setup, Signed JWT setup, and Access and roles.