Separate sign-in, account creation and permissions
Single sign-on (SSO) lets an operator use an external identity provider in the application’s sign-in process. This guide covers the Microsoft and Google configurations available in a Lexoh installation. Confirm the supported provider, protocol and setup controls with the responsible administrator.
OAuth 2.0 is an authorization framework. OpenID Connect adds an identity layer for authentication. A provider option labelled OAuth2 does not by itself document the connector’s complete authentication flow or security controls.
A successful provider sign-in does not establish every application permission. Review account linking, creation rules, roles and record scope separately. Also confirm any local sign-in route that remains available and the provider policies that actually apply, including multifactor authentication.
Protocol reference: OpenID Connect Core.
Prepare the provider connection and recovery path
- Identify the approved organization, operator population, application environment and configuration owners. Record the current settings and preserve a separately verified administrative recovery path.
- Confirm who manages the provider’s application registration. Use the connector’s documented callback address and required settings; do not invent a redirect path from the public website URL.
- Where registration or consent is required, review the intended application, requested permissions and eligible users with the provider administrator. Confirm supported credential storage and renewal if a client secret or certificate is needed.
- Define how identities match existing accounts, whether new accounts may be created and what initial permissions they receive. Check renamed users, duplicate email addresses and any manually assigned roles.
- Save and reopen the supported SSO settings to verify the non-secret values. Test with designated identities before wider use. Keep the original configuration and recovery procedure available until the tests are complete.
Verify Microsoft tenant and group mappings
Microsoft Entra ID is the current name for Azure Active Directory. For the Microsoft connection, verify the intended tenant, application and permitted account types. Review guest access explicitly; an organizational email address alone does not establish the intended tenant relationship.
Microsoft’s ID-token reference distinguishes tenant identity from user identity and warns that readable fields such as email can change or be reused. Confirm the connector’s stable account-linking method rather than relying on a matching display name or email address.
Tenant selection
Obtain the tenant reference through the provider’s administrative tools or a supported Lexoh control. Check the value against the approved organization. A successful lookup does not prove that other tenants or account types are denied.
Group-to-role mapping
If mapping is available, verify each source group and target role, multiple-membership precedence and the result for an unmapped user. Microsoft documents limits on group claims and differences in nested-group behavior. Confirm how the connector handles the configured claim format, missing groups or an overage result; do not assume every group is always present.
Changes after first sign-in
Check whether mappings apply only during account creation, at each sign-in or through another process. Test removal from a mapped group and compare existing sessions with new sign-ins. A manual role edit may interact with later synchronization.
Microsoft references: ID-token claims and user identifiers. Group-claim configuration and limits.
Verify Google organization restrictions and account linking
For Google sign-in, define the approved Workspace organizations and account population. Use the format required by the current Lexoh settings; confirm how multiple domains and an empty restriction are handled.
Google documents that the request’s hd parameter is a sign-in hint. Restriction to a hosted organization requires checking the hd claim in a validated ID token; an email suffix is insufficient. Google also recommends its stable sub identifier for linking users rather than email. Verify these controls in the connector before relying on a domain field.
If a default role or first-sign-in account creation is supported, choose the approved initial scope and test the resulting account. Verify existing-user behavior separately. Do not infer that any Google account receives access merely because the provider button appears.
Google reference: OpenID Connect: domain claims and user identity.
Test the intended access boundary
The following checklist is an illustrative acceptance plan for an organization-only deployment. Use designated accounts and an approved test procedure. Record the provider identity, linked Lexoh reference, expected outcome, actual outcome and time. These are requirements to verify, not claims about an already-tested installation.
| Test case | Required result for this example |
|---|---|
| Approved operator from the intended organization | Sign in to the correct account with only the approved role and record scope. |
| Account from an excluded organization or a personal account | Deny application access under the organization-only policy. |
| Valid provider account with no approved role mapping | Follow the defined denial or restricted-enrollment policy; do not grant unintended privileges. |
| Operator removed from the authorized population | Deny new sign-in as specified and verify removal of existing application access through the supported procedure. |
| Administrator recovery during a provider failure | Use the separately approved recovery path without broadening access for other users. |
Check actions as well as sign-in
After successful sign-in, test a required action and an excluded action with approved records. Include tenant or site scope where relevant. Coordinate any equipment command with site operations. A displayed role name or hidden menu does not establish the effective permissions.
Find the stage that needs correction
Provider button is missing
Check the saved provider setting, application environment and supported sign-in route. Confirm feature availability and any relevant account or policy restrictions before changing the configuration.
Redirect, registration or consent error
Compare the callback address and application registration with the connector’s documented values. Have the provider administrator review required consent and allowed users. Preserve the non-secret error or correlation reference.
Provider accepts the user but Lexoh denies access
Inspect organization restrictions, account association, application status and role mapping. Distinguish provider authentication from the application’s authorization decision.
Wrong account or permissions after sign-in
Review stable identity linking, guest or tenant context, default-role rules and group mapping. Check for an existing account before creating another one; preserve evidence of unexpected access for the administrator.
Access remains after removal
Check the saved provider and application changes, propagation behavior and supported session revocation. Signing out of the provider or removing group membership alone does not prove that an existing Lexoh session has ended.
Maintain SSO, sessions and recovery
Assign owners to the provider connection, eligible-user rules, role mappings and any expiring application credentials. Review changes when people, sites or responsibilities change and at intervals appropriate to the organization. Keep a dated record of the tests and the application version.
Document sign-out and offboarding behavior for the provider, Lexoh sessions, local sign-in and separately managed physical credentials. Confirm how each access path is withdrawn. A central identity provider can support access management, but its presence does not verify the entire departure workflow.
Use a recovery method supported by the installation and approved by the organization. If a local emergency account is part of that method, protect and monitor it, test it periodically and keep its use limited to its intended purpose. Do not assume a local fallback exists in every deployment.