Core concepts

The dozen words the rest of the documentation relies on, each defined once.

Tenant#

One application protected by Shield, with its own configuration, its own sign-in page, its own keys and its own records. Everything in your console is scoped to your tenant, and no other tenant can see it.

A tenant has a status:

Status	Meaning
Draft	You submitted the onboarding form. A VERISCO administrator has not reviewed it yet.
Approved	Reviewed and accepted. Not yet serving sign-ins.
Published	Live. Sign-ins work, and your route is in place.
Suspended	Switched off by an administrator. Sign-ins are refused until it is reactivated.

Realm#

Each tenant has its own isolated authentication domain, called a realm. It holds your sign-in flow, your multi-factor settings and your users' enrolled factors. It does not hold their passwords: those stay where they are.

Identity source#

Where your users are read from: your own MySQL database or your LDAP / Active Directory. Shield checks each password against it at sign-in. See Identity sources.

Deployment mode#

How Shield reaches your application: a gateway in front of it, a connector that tunnels out from your network, or an SDK inside it. The mode decides where controls are enforced. See Deployment modes.

The assertion#

After a successful sign-in, Shield signs a statement of who the user is with your tenant's private key (RS256). Your application receives it as the verisco_session cookie and, behind the gateway, as the X-Verisco-Claims header. Both carry the same signed token, and your application must verify it with your tenant's public key before trusting it. See Read the signed-in user.

Pass-through and protected#

A newly published tenant is in pass-through: your hostname goes through Shield, a signed identity is passed along when there is one, and nobody is blocked. When your code is ready you go live, and from then on every request requires a sign-in. See Going live.

Policy#

A set of rules you write in the console: password, lockout, session, network and device. Network and device policy each have a mode:

Mode	What happens
Off	The policy is not evaluated.
Watch	Every decision is evaluated and recorded. Nobody is stopped.
Enforce	The policy is applied.

Watch mode is what makes a safe rollout possible: you see who a rule would have stopped before it stops anyone.

Decision#

The outcome of evaluating policy for one sign-in: allow, challenge (ask for a second factor) or deny. Each one is recorded with its reason on the Sign-in Activity page.

Session#

A signed-in period for one user. It has a maximum lifetime and an idle timeout, it can be ended from the console, and on Premium it can be bound to the network and browser it started on.

Revocation#

Ending a session or signing a person out. It is a not-before time, not a ban: sessions issued before it stop being accepted, and the person can sign in again afterwards.

Plan and licence#

Your plan decides which features you have. Your licence is the term you paid for. See Plans and billing.

Role#

What a member of your team may do in the console: Auditor, Helpdesk, Administrator or Owner. See Team and roles.

Something missing or wrong on this page? Tell us and we will fix it.