Overview

Connect GAccess to your organisation's identity platform for centralised authentication and automated user lifecycle management


Identity Providers

Overview

GAccess supports integration with external identity providers, allowing your organisation to use its existing identity platform as the authoritative source for user authentication and lifecycle management. When an identity provider is configured, users authenticate through it rather than managing a separate GAccess password — delivering a consistent single sign-on experience across your environment.

Beyond authentication, identity provider integration unlocks automated user and group provisioning: accounts can be created, updated, and deactivated in GAccess automatically as they change in the source system, reducing manual administration and ensuring that access is revoked promptly when employees leave.


Benefits

Single sign-on — Users authenticate once with your corporate identity provider and are granted access to GAccess without a separate credential. This reduces password fatigue and simplifies the login experience.

Centralised access control — User accounts and group memberships are managed in a single authoritative system. Changes made in the identity provider — such as adding a user to a privileged access group or disabling a leaver — are reflected in GAccess automatically.

Automated provisioning — New users can be provisioned into GAccess on their first login or via SCIM 2.0 push from the identity provider, eliminating the need to manually create accounts.

Reduced credential sprawl — Users do not need a separate GAccess password. Authentication credentials remain under the governance of your existing identity platform and its MFA and conditional access policies.

Audit continuity — All SSO login events, user provisioning events, and group membership changes are recorded in the GAccess audit log, giving you a complete picture of who accessed the system and how.


Supported identity providers

Provider Status Protocol
Microsoft Entra ID Available OAuth 2.0 / OIDC
Okta Coming soon —
Google Workspace Coming soon —
LDAP Coming soon —

Breaking glass accounts

When SSO is the primary authentication method, it introduces a dependency on the availability of the external identity provider. If the identity provider becomes unreachable — due to a network outage, misconfiguration, or a service disruption — no SSO-authenticated user would be able to log in.

A breaking glass account is a local GAccess account reserved exclusively for emergency access in exactly this scenario. It authenticates directly against GAccess and is never federated to an external identity provider, so it remains accessible regardless of SSO availability.

Characteristics of a breaking glass account:

  • Authenticates with a local username and password — never via SSO.
  • Cannot be managed, deactivated, or deleted through SCIM provisioning.
  • Cannot be converted to a federated account.
  • Access events are recorded in the audit log and should be treated as high-priority alerts in normal operations.

Recommendations:

  • Create at least two breaking glass accounts, stored and managed independently, so that loss of one does not eliminate emergency access.
  • Use strong, randomly generated passwords of at least 32 characters.
  • Store the credentials in an offline or out-of-band secure storage (physical safe, hardware security module, or a separate secrets manager that does not depend on GAccess availability).
  • Test breaking glass accounts quarterly to confirm they are accessible and functional.
  • Set up monitoring alerts so that any use of a breaking glass account triggers immediate investigation — routine use of these accounts is a signal that something is wrong.
Warning: Avoid a complete lockout GAcces will enforce the creation of at least 2 break glass accounts before proceeding with the external identity provider configuration.

Managing breaking glass accounts

Creating a breaking glass account

Breaking glass accounts are created from Settings → Users → Create User by administrators with the create permission on BreakGlassAccount entity.

Requirements at creation time:

  • Password must be at least 12 characters.
  • The account is activated immediately — no invitation email is sent.
  • MFA is mandatory. Upon creation, GAccess generates a TOTP secret and QR code. You must scan the QR code with an authenticator app and store the 8 one-time backup codes in secure offline storage before closing the creation dialog. These are shown only once.

GAccess enforces a minimum of two breaking glass accounts at all times. If only one exists, a warning is shown. If only two exist, neither can be deleted or have its breaking glass designation removed until a third is created.


Rotating the password

Breaking glass account passwords are rotated by an administrator from Settings → Users → [account] → Reset Password (Admin).

To perform this operation the administrator must provide the account's current password to authorize the rotation. This prevents an attacker with administrative access from silently replacing a breaking glass credential without knowing the existing one.

No email is sent at any stage of this operation. The new password is displayed once in the interface and must be stored securely by the administrator before closing the dialog.

If the current password has been lost and rotation is blocked, recovery requires out-of-band support — there is no automated self-service path.

Note: Breaking glass accounts are exempt from force-password-reset policies. Administrators cannot push a mandatory password change to these accounts; all resets must be performed using the admin reset flow described above.

Password expiration

Breaking glass passwords are subject to the tenant's password expiration policy (default: 90 days). The account detail view shows the password age and displays a warning when expiration is approaching.

If a breaking glass password expires, the account will require an admin password reset before it can be used. To avoid discovering an expired credential during an actual emergency, test breaking glass accounts on a regular schedule and rotate passwords before they expire.


What emails are sent

No emails are sent for any breaking glass account operation:

Operation Email sent?
Account creation No
Password rotation No
Self-service password reset Not available — blocked
Self-service forgot password Not available — blocked

All credential delivery is the administrator's responsibility. Store passwords and backup codes in offline or out-of-band secure storage that does not depend on GAccess or the identity provider being available.


Restrictions

The following operations are permanently blocked for breaking glass accounts to preserve their integrity as a last-resort access mechanism:

Operation Behaviour
Disable or deactivate the account Blocked — a disabled account cannot serve its emergency purpose
Convert to a federated (SSO) account Blocked — breaking glass accounts must remain local-only
Self-service password reset or forgot password Blocked — all resets go through the admin reset flow
SCIM provisioning, update, or deactivation Blocked — the identity provider cannot affect these accounts
Reduce the total count below 2 Blocked — deletion or removal of the breaking glass designation is rejected if it would leave fewer than 2 accounts