VERISCO Shield Get started
How it works
The components, the path of one sign-in, and what is kept where.
The components#
| Component | What it does |
|---|---|
| Gateway | The reverse proxy in front of your application. Terminates TLS, checks the session on every request, and forwards the request with the signed identity. Used in gateway and connector mode. |
| Sign-in realm | The identity provider, one isolated realm per tenant. Hosts your sign-in page and runs the factors. |
| Directory connector | The part of the realm that checks a password against your MySQL database or your LDAP directory. |
| Control plane | Your console. Holds your configuration, evaluates network and device policy, records decisions, and applies your settings to the realm. |
| Connector agent | Optional. Runs in your network and dials out to VERISCO, so your application and database need no inbound access. |
| Device agent | Optional. Runs on your staff's machines and reports their security posture. |
| Middleware | The library in your application that verifies the signed identity, or, in SDK mode, performs the sign-in itself. |
One sign-in, step by step#
- A user opens your application's address.
- The gateway looks for a valid
verisco_sessioncookie. There is none, so the user is sent to your sign-in page. - The sign-in page checks the captcha, the network policy and the device policy, then checks the password against your own directory.
- If your policy requires it, the user completes a second factor.
- The realm returns an authorisation code to the gateway, which exchanges it, reads the user's row from your directory for the role and profile fields, and signs an assertion with your tenant's private key.
- The gateway sets the session cookie and forwards the request to your application with the assertion in
X-Verisco-Claims. - Your application verifies the signature with your public key and reads the user.
On every later request the gateway checks the session again before your code runs: its lifetime, its idle time, whether it was revoked, and, on Premium, whether it moved to another network.
In SDK mode there is no gateway. Your application performs steps 2, 5, 6 and 7 itself, and asks VERISCO every 30 seconds what to enforce.
What is kept where#
| Data | Where it lives |
|---|---|
| Usernames and password hashes | Your database or directory. Read at sign-in, never copied. |
| Enrolled factors (authenticator secrets, passkeys, recovery codes) | Your tenant's sign-in realm. |
| Your tenant's signing key | The control plane, private half encrypted at rest. The public half is yours to download. |
| Your database credentials | The control plane, encrypted at rest. |
| Sign-in decisions, sessions, device checks | The control plane, subject to your privacy settings and retention. |
| Configuration changes | The hash-chained audit log. |
Read-only by default#
Shield connects to your database with a user that only needs SELECT on your users table. In this mode it never writes to your database, and password changes stay in your own application.
You can instead grant write access to the password column. That lets your users reset a forgotten password on the sign-in page and lets Shield enforce password history and expiry. See Identity sources.
What fails, and how#
| If this stops | What your users see |
|---|---|
| Your directory is unreachable | Sign-in fails. Existing sessions keep working until they expire. |
| The connector agent stops | Your application is unreachable through VERISCO until it reconnects. Sign-in itself still works. |
| VERISCO is unreachable, gateway or connector mode | Your application is unreachable through VERISCO. |
| VERISCO is unreachable, SDK mode | Your application keeps working on the last state it received. A revocation made in that window has not arrived yet. |
Something missing or wrong on this page? Tell us and we will fix it.