Single sign-on

Federated sign-in is the control that makes offboarding real. Deactivate an account in your identity provider and access to AutoPQC ends without anyone remembering to remove a seat. This page is written for an identity team: what protocol we speak, what assertion we need, how groups become roles, and what breaks if a claim is missing.

#What we federate, and what we do not

AutoPQC acts as a service provider (SAML) or a relying party (OIDC). Your identity provider remains the source of truth for who a person is, whether they are still employed, and what factors they presented. We never see a password and never store one for a federated user.

SAML 2.0

Service-provider-initiated and identity-provider-initiated flows. HTTP-POST binding for the assertion. Signed assertions required; signed responses accepted. Any conformant SAML 2.0 provider should work — we do not maintain a list of blessed vendors, because a conformance list ages badly.

OIDC

Authorisation code flow with PKCE. Discovery via the provider's well-known configuration document. The openid, email and profile scopes at minimum, plus whatever scope carries group membership in your provider.

Multi-factor

Enforced by you, asserted to us. We read the authentication context in the assertion and record it in the activity log. We do not implement a second factor of our own for federated users, because two independent MFA policies is one too many.

Session lifetime

Derived from the assertion where the provider supplies a session expiry, subject to our own maximum. [PLACEHOLDER: maximum session lifetime and idle timeout values]

#The claims we require

A federated sign-in fails closed. If a required claim is absent we reject the assertion and surface the specific missing attribute rather than a generic failure, so the fix is a one-line change in your provider rather than a support thread.

#Mapping groups to roles

The role set is fixed and small — owner, administrator, security lead, engineer, auditor — and is described in Roles and permissions. Federation maps your groups onto those roles per workspace.

1. 01You nominate the group claim and the group values you intend to use. Values are matched exactly and case-sensitively, so agree the strings once and write them down.
2. 02Each group value is mapped to one role in one workspace. A group can map into several workspaces; a workspace can accept several groups.
3. 03Where a person's groups resolve to more than one role in the same workspace, the least privileged mapping wins. Broad accidental membership should not grant administrator.
4. 04Where a person's groups resolve to no mapping at all, sign-in is refused. There is no default role and no implicit read access.

The owner grant is never derived from a group. It is held by a named person and changes only through an explicit ownership transfer, so that a group-membership mistake cannot hand over the commercial relationship.

#Provisioning and deprovisioning

Just-in-time provisioning is how accounts get created. The first time a mapped person signs in successfully, we create their account from the assertion and grant the role their groups resolve to. No invitation, no manual seat allocation, no list to keep synchronised.

Deprovisioning is the harder half and it needs stating plainly. When you remove someone from a mapped group, their next sign-in fails and any active session is invalidated at its next validation point. What does not happen automatically is the removal of the account record itself, and any credential they personally issued for automation remains valid until it is revoked.

• Do include AutoPQC in your joiner-mover-leaver runbook rather than assuming group removal is sufficient.
• Do review automation credentials on a schedule, as described in API and automation surfaces.
• Do not rely on a person's group removal to stop a scheduled export they configured. Credentials outlive sessions.

#Enforcing SSO-only sign-in

Federation configured alongside password sign-in is a convenience, not a control. Enforcement is what turns it into one: with SSO enforced, password authentication is refused for every member of the organisation, and the only path in is through your identity provider.

1. 1

   Configure and verify the connection

   Exchange metadata, agree the claim names, and confirm a test sign-in resolves to the role you expect. Verify with a person who holds a low-privilege role, not with the owner.

2. 2

   Map every existing member

   Any member who is not covered by a group mapping loses access the moment enforcement is switched on. Reconcile the member list against your groups before, not after.

3. 3

   Designate a break-glass account

   One named account, exempt from enforcement, protected by a strong second factor, with its credential held in your privileged-access store. It exists for the day your identity provider is unreachable. Every use of it is written to the activity log.

4. 4

   Enforce, then test the failure path

   Confirm that a password sign-in is refused and that the break-glass path works. A break-glass account nobody has ever tested is a comforting story rather than a control.

We will not publish specimen values for the service-provider endpoints, because a wrong one copied from a documentation page is a debugging session nobody enjoys. The values you need are: [PLACEHOLDER: SAML assertion consumer service (ACS) URL], [PLACEHOLDER: SAML service provider entity ID], [PLACEHOLDER: OIDC redirect URI], and [PLACEHOLDER: SAML metadata URL]. They are issued per organisation.