Single Sign-On (SSO)
Configure SAML 2.0 single sign-on, verify organization domains, provision members, and enforce identity-provider authentication.
Single sign-on lets organization members authenticate to SikkerKey through your SAML 2.0 identity provider. Your organization keeps control of the sign-in policy while SikkerKey continues to enforce each member’s vault role and access role after authentication.
SSO applies to organization vaults on plans that include the feature. Only the vault owner can configure it.
#Before you begin
Administrator access to your SAML 2.0 identity provider
Access to create an enterprise application or service-provider integration in the identity provider
Access to publish a DNS TXT record for each email domain the organization will use
An organization vault on a plan that includes SSO
The email attribute or email-formatted NameID your identity provider will send for each user
The SSO page appears under Organization when the active vault and subscription support the feature.
#SAML values used by SikkerKey
Term | Purpose |
|---|---|
Service provider entity ID | The stable identifier for your organization’s SikkerKey SAML service provider. It is also the expected assertion audience. |
ACS URL | The Assertion Consumer Service endpoint where your identity provider posts the signed SAML response. |
Metadata URL | A SAML metadata document your identity provider can import to obtain SikkerKey’s service-provider information and signing certificate. |
IdP entity ID | The issuer identifier SikkerKey expects inside signed assertions. |
IdP SSO URL | The HTTPS endpoint where SikkerKey sends signed authentication requests. |
IdP signing certificate | The public X.509 certificate SikkerKey uses to verify assertions from your identity provider. |
#Configure your identity provider
Open Organization → SSO in the SikkerKey dashboard.
Under Service provider details, copy the Entity ID, ACS URL, and Metadata URL.
Create a SAML 2.0 application for SikkerKey in your identity provider.
Enter the SikkerKey entity ID as the service-provider identifier or audience.
Enter the ACS URL as the reply, callback, or assertion-consumer URL.
Configure your identity provider to send the member’s work email as the NameID or a supported email attribute.
Set the application to sign the SAML assertion.
Export or copy the identity provider’s metadata, entity ID, SSO URL, and signing certificate.
SikkerKey starts sign-ins through a signed SAML authentication request using the HTTP-POST binding. Configure the identity provider to accept service-provider-initiated requests and return its response to the organization-specific ACS URL.
Import the SikkerKey Metadata URL when your provider supports service-provider metadata. This reduces manual entry and keeps the entity ID, ACS URL, and signing certificate together.
#Connect the identity provider in SikkerKey
You can configure the identity provider from its metadata file or enter the fields manually.
Upload identity-provider metadata
Under Identity provider, select Upload.
Choose the SAML metadata XML supplied by your identity provider.
Review the entity ID, SSO URL, and signing certificate extracted from the file.
Check that the values belong to the intended identity-provider tenant.
Continue with domain verification before enabling SSO.
Metadata upload accepts a bounded XML document and extracts the first SAML 2.0 identity-provider descriptor, a POST or Redirect sign-in endpoint, and a signing certificate. SikkerKey parses only the uploaded document and does not fetch external resources referenced by it.
Enter the values manually
Enter the IdP entity ID exactly as your provider publishes it.
Enter the IdP SSO URL. The endpoint must use HTTPS.
Paste the IdP signing certificate in PEM format.
Review the certificate fingerprint and expiry shown by the dashboard.
Save after completing domain verification and choosing the SSO policy.
SikkerKey rejects a certificate that is malformed, expired, or not yet valid when it is saved. Replace a certificate before its displayed expiry and update SikkerKey when your identity provider rotates its signing key.
Changing the entity ID or signing certificate changes the trust relationship. Confirm the new fingerprint through a trusted identity-provider administration channel before saving it.
#Verify your email domains
SikkerKey admits and provisions SSO users only from domains the organization has proven it controls. Verification also connects the Continue with SSO email-discovery flow to the correct organization.
Enter the domain under Verified domains, such as acme.com.
Select Add domain.
Copy the DNS record name and value shown by SikkerKey.
Publish the TXT record with your DNS provider.
Wait for DNS propagation.
Return to the SSO page and select Verify.
The record name uses _sikkerkey-verification.<domain>. SikkerKey marks the domain verified only when the TXT value exactly matches the generated verification token.
Pending claims do not reserve a domain. Once verified, a domain can belong to only one SikkerKey organization. This prevents another organization from using the same domain for SSO discovery or just-in-time provisioning.
You must verify at least one domain before SSO can be enabled. Add and verify every email domain that legitimate members may use.
Removing a domain
Removing a domain stops SSO discovery and just-in-time admission for addresses in that domain. Members using it can no longer start a new SSO session through the organization.
Removing a domain does not remove existing organization memberships. Review the Members page and active access separately when retiring a domain.
#Enable or enforce SSO
Setting | Member experience | Existing sessions |
|---|---|---|
Disabled | SSO discovery and SAML sign-in are unavailable. | Existing SikkerKey sessions continue until otherwise revoked or expired. |
Enabled | Members may use SSO while password, passkey, or OAuth sign-in remains available. | Current sessions continue. |
Enabled and enforced | Non-owner accounts in verified domains must use the identity provider. Password, passkey, OAuth, and new password registration are refused. | When enforcement is first enabled, SikkerKey immediately revokes matching non-owner sessions so the policy takes effect. |
The vault owner is always exempt from SSO enforcement. The owner retains their existing SikkerKey authentication as a break-glass path for correcting a certificate, domain, or identity-provider configuration problem.
Test an ordinary member’s SSO login before enabling enforcement. Keep the owner’s password, passkey, and recovery material available in a protected location.
Save protected changes
If the vault owner uses WebAuthn passkeys, saving the SSO trust configuration and adding or removing a domain requires a recent passkey verification. The verification is consumed after the change.
Configuration and domain changes are written to the Audit Log, including certificate fingerprint changes and whether SSO or enforcement was enabled.
#How members sign in
On the SikkerKey login page, select Continue with SSO.
Enter the work email address or organization domain.
SikkerKey finds the enabled organization associated with the verified domain.
SikkerKey creates and signs an authentication request and sends the browser to the configured identity provider.
The member authenticates according to the identity provider’s policies.
The identity provider posts the signed response to SikkerKey’s ACS URL.
SikkerKey validates the response, creates or resolves the organization membership, and starts a SikkerKey session in that organization vault.
Discovery returns the same generic result for unknown, unverified, and SSO-disabled domains. This prevents the public sign-in flow from revealing which organizations use SikkerKey.
#Just-in-time provisioning
A person does not need to be invited before their first SSO login. If the identity provider authenticates them and the asserted email belongs to a domain verified for the organization, SikkerKey can provision the account and membership automatically.
Existing SikkerKey account. The account is attached to the organization when the email matches and the account is active.
New SikkerKey account. SikkerKey creates an active passwordless customer account and adds it to the organization.
Existing organization member. The current membership is reused. A suspended membership is refused rather than restored by SSO.
New organization member. The member starts with the Collaborator vault role and no access role.
Unverified domain. Provisioning is refused even when the SAML assertion is otherwise valid.
The default role combination gives a newly provisioned member only the vault overview and their own audit activity. They cannot reach an application or project until the owner assigns an access role.
After the first login, use Organization → Members to assign the appropriate vault role and access role.
Review newly provisioned members regularly. SSO proves identity and domain membership; SikkerKey roles determine what the authenticated person can access.
#Assertion validation
SikkerKey validates the complete SAML exchange before trusting the asserted identity.
The SAML response must report a successful status and contain exactly one assertion.
The assertion itself must be signed by the configured identity-provider certificate.
The signature profile and algorithms must meet SikkerKey’s modern allowlist; weak SHA-1, MD5, DSA, HMAC, and RSA 1.5 key-transport choices are rejected.
The assertion issuer must exactly match the configured IdP entity ID.
The audience must contain the organization’s SikkerKey service-provider entity ID.
The bearer recipient must exactly match the organization’s ACS URL.
The Conditions and SubjectConfirmation validity windows must be current, with only limited clock-skew allowance.
The assertion must contain an authentication statement and a usable subject identity.
The InResponseTo value must match a pending authentication request created by SikkerKey.
The pending request and assertion identifier are consumed once, preventing replay.
Encrypted assertions are accepted only with approved data-encryption and RSA-OAEP key-transport algorithms.
Unsolicited identity-provider-initiated assertions are rejected. SikkerKey accepts responses only for a service-provider-initiated login it recorded.
Detailed validation failures are recorded for security review while the browser receives a generic sign-in error.
#Protected configuration storage
The identity-provider entity ID, SSO URL, signing certificate, and uploaded metadata are encrypted at rest with authenticated encryption. This protects the trust configuration against undetected database-only modification.
SikkerKey displays the signing certificate’s SHA-256 fingerprint and expiry so the owner can compare it with the identity provider and plan certificate rotation.
SSO sign-ins, failures, configuration changes, and domain changes appear in the Audit Log. The broader authentication and session model is described in the Security Overview.
#Member removal and identity-provider changes
Disabling a person at the identity provider prevents them from creating a new SSO session, but SikkerKey does not currently receive automatic deprovisioning events from the provider.
To fully remove access:
Disable or remove the user from the SikkerKey application in the identity provider.
Open Organization → Members in SikkerKey.
Suspend or remove the organization membership.
Review the Audit Log and active sessions during the access-removal process.
Removing or suspending the SikkerKey membership ensures the authorization layer refuses further organization access independently of the identity provider.
#Certificate rotation
Obtain the new signing certificate or updated metadata from the identity provider.
Confirm the new SHA-256 fingerprint through a trusted administrator channel.
Upload the new metadata or replace the PEM certificate in SikkerKey.
Save the configuration and complete passkey verification when prompted.
Test a member SSO login.
Confirm the successful login and certificate change in the Audit Log.
Coordinate the activation time with the identity provider. SikkerKey validates assertions against the single certificate currently saved for the organization.
#Troubleshooting
Symptom | What to check |
|---|---|
SSO cannot be enabled | Verify at least one email domain and complete all three identity-provider fields. |
Metadata upload fails | Confirm that the file is SAML 2.0 identity-provider metadata and contains an entity ID, SSO endpoint, and signing certificate. |
Certificate is rejected | Use a valid X.509 PEM certificate whose validity period has started and has not expired. |
Domain remains pending | Confirm the TXT name and value, then allow time for DNS propagation before selecting Verify again. |
Organization is not found from the login page | Confirm that the entered domain is verified, SSO is enabled, and the plan still includes SSO. |
Identity provider accepts login but SikkerKey refuses it | Check the issuer, audience, ACS recipient, assertion signature, email claim, validity window, and whether the flow began from SikkerKey. |
New member can sign in but sees no projects | Assign an access role. Just-in-time members intentionally start with none. |
Existing member is refused | Confirm that the SikkerKey account and organization membership are active and not suspended. |
Members can still use another sign-in method | Enable Enforce SSO after testing the SAML flow. |
Members lose access after enforcement | Use the owner break-glass login to correct the IdP, domain, or certificate configuration. |
Keep a certificate-rotation reminder, test SSO after identity-provider changes, and retain the owner break-glass credentials independently of the identity provider.