Account security and recovery

Workspace delegates passwords and passkeys to the deployment’s identity provider. Open Account security → Manage sign-in and recovery to manage these methods. Your organization membership and scientific project permissions remain separate.

Add and test a passkey

On a supported, correctly configured HTTPS deployment, open the provider’s Signing in page and add a passkey. Follow your browser’s device or security-key prompt. Keep an approved fallback method while testing. End the provider session, then select Sign in with Passkey on a fresh login. Signing out of Workspace alone does not necessarily end the identity provider’s SSO session.

The private Keycloak pilot has passed virtual CTAP2 enrollment and a fresh passwordless assertion with user verification. An uninvited test identity remained denied by Workspace. Physical Touch ID, synced passkeys and hardware-key acceptance are still separate customer/device qualification steps.

If the hostname does not resolve, contact IT about DNS/network configuration. Passkeys are bound to the configured relying-party hostname; a different address or an insecure certificate workaround is not an equivalent test.

Password recovery

When IT has configured and tested the provider’s email service, use Forgot password at sign-in. Use only the newest valid recovery message. If none arrives, check spam and ask IT to inspect delivery; avoid repeated requests. A local captured mail test is not proof of internet delivery. The private pilot now has a verified Proton-to-Gmail recovery test: receipt, password reset, fresh login and rejection of the old password passed. This does not qualify every customer mail provider. Workspace invitation delivery is a separate qualified workflow.

When a project access key is refused

The account page shows, beside Last used, when a key was Last refused, by which kind of application (QGIS, Python, Browser or another application) and why, in plain words; a key that expired in the last 14 days stays listed, marked Expired, so you can see that it was refused for that. A key that never reached the server (a header lost on the way) cannot be shown there: ophiolite doctor --online --key-file key.txt checks the key from your computer. What each answer means:

What you read	Stage	What to do
No credential reached Ophiolite; check the application’s authentication settings. (QGIS: the layer is not valid, 401)	no-credential	The key did not arrive. Most often the value in QGIS’s API Header ends with a line break: open the configuration, delete the value and paste it again with the command above (Bearer , one space, the key, nothing after it).
The Authorization header is not a bearer credential of a kind Ophiolite accepts.	malformed-credential	The value is not Bearer and one key: check the scheme is Bearer, there is one space, and no space or line break inside the key.
Project access key revoked or expired	credential-refused	The key is unknown, expired or removed: create a new key on the account page and put it in the application.
Project access key scope denied, or Owner no longer has this access	access-denied	The key works but not for this: use a key for this project with the scope you need, or ask a project administrator.
cannot reach the server: check Tailscale (from ophiolite doctor --online)	address or tls	The deployment is private to its tailnet: connect Tailscale on this computer and try again.

Operational scope

The single-VPS pilot now uses a persistent identity database, service startup units, encrypted off-site backups and readiness checks. Database restoration was tested in isolation, and encrypted remote read-back was verified. These do not establish a complete machine-loss recovery drill or high availability. IT owns provider/network policy, secrets, backup retention and monitoring. End users manage their own allowed sign-in methods and sessions; project owners separately control scientific data access.