VERISCO Shield Integrate
Deployment modes
Three ways for Shield to reach your application. The difference between them is not a feature list. It is who holds the guarantee.
In gateway and connector mode the enforcement sits outside your application and cannot be undone by anything you deploy. In SDK mode it sits inside your application: correct while the middleware is mounted, and gone the moment someone removes it. Both are defensible. They are not the same.
The three modes#
VERISCO gateway#
VERISCO sits in front of your application.
| Best for | Applications the internet can already reach, in any language or framework. |
| You need | A public hostname you control. |
| Who enforces | VERISCO, in front of your application. Nothing in your code can switch it off. |
| What you do | Point your hostname at VERISCO. Give us an address VERISCO can reach (host:port). Add the VERISCO middleware so your app reads the signed-in user. |
VERISCO connector#
A small agent in your network dials out to VERISCO. Nothing of yours has to be reachable from the internet.
| Best for | Applications or user databases on a private network the internet cannot reach. |
| You need | One machine in your network that can open outbound HTTPS connections. |
| Who enforces | VERISCO, in front of your application, exactly as with the gateway. |
| What you do | Run one install command on a machine that can reach your app and database. Point your hostname at VERISCO. Add the VERISCO middleware so your app reads the signed-in user. |
VERISCO SDK#
Your application talks to VERISCO directly. Your DNS and your servers do not change.
| Best for | Node.js applications (Express or Connect) where nothing can sit in front. |
| You need | Node.js with Express or Connect. |
| Who enforces | Your application, through the VERISCO SDK. Changes reach it within 30 seconds. |
| What you do | Install the VERISCO package with npm. Mount it in your application with your client ID and secret. Keep your DNS and servers exactly as they are. |
| Not available | The user's own sessions and devices page; The VERISCO WordPress plugin; Any language or framework. |
What each mode does for each control#
This table is generated from the same source as the labels in your console, so the wording matches what you see there.
| Control | Gateway | Connector | SDK |
|---|---|---|---|
| Sign a user out / end one session | Refused within 5 seconds, at the gateway. | Refused within 5 seconds, at the gateway. | Takes effect in your application within 30 seconds. |
| Session binding (network / device drift) | Checked on every request, before your app sees it. | Checked on every request, before your app sees it. | Checked in your application on every request. Needs your framework's proxy trust set correctly, or the address it compares is your load balancer's. |
| Licence enforcement | Applies to every sign-in, in every deployment mode. | Applies to every sign-in, in every deployment mode. | Applies to every sign-in, in every deployment mode. |
| Sealing the application's own login page | Returns 404 at the gateway. Your page is unreachable from outside. | Returns 404 at the gateway. Your page is unreachable from outside. | The middleware returns 404 for it, within 30 seconds of the change. It only covers routes the middleware is mounted on. |
| Public paths (no sign-in required) | Served without a session, by the gateway, before your application is reached. | Served without a session, by the gateway, before your application is reached. | Applied by the middleware, so it only covers routes you mounted it on. A route you protect by hand is not affected by this list. |
| Unauthenticated health check | The gateway lets exactly this path through without a session. | The gateway lets exactly this path through without a session. | Used by VERISCO to check your application is up. Your own code decides what it serves. |
| The user's own sessions and devices page | Served by VERISCO at /verisco/me on your hostname. | Served by VERISCO at /verisco/me on your hostname. | Not available. VERISCO serves nothing on your hostname in this mode, so there is no page to serve. Connector mode keeps it. |
| User activity and SIEM export | Recorded by the gateway as it happens. | Recorded by the gateway as it happens. | Reported by the middleware in batches, so activity appears within about 30 seconds. |
| Roles and profile fields from your database | The gateway reads your user row and signs it into the assertion your app receives. | The gateway reads your user row and signs it into the assertion your app receives. | The ID token carries the role your directory returns. Anything more comes from your own enrichment hook. |
| Device posture checks | At sign-in, and re-checked on later requests. | At sign-in, and re-checked on later requests. | At sign-in, and re-checked in your application within 30 seconds of a change. |
| MFA, captcha, password rules, lockout, network policy | Applies to every sign-in, in every deployment mode. | Applies to every sign-in, in every deployment mode. | Applies to every sign-in, in every deployment mode. |
| The VERISCO WordPress plugin | Supported. The plugin lets WordPress keep its own admin login while VERISCO protects the rest. | Supported. The plugin lets WordPress keep its own admin login while VERISCO protects the rest. | Not available. The plugin relies on VERISCO sitting in front of WordPress. Use connector mode. |
| Any language or framework | Your application reads one header. Any stack. | Your application reads one header. Any stack. | Not available. The SDK is Node only for now. Connector mode works with any stack. |
| Reaching your user database | VERISCO connects to your database directly, so it has to be reachable from VERISCO. | Reached through the connector, so your database stays on your private network. | VERISCO connects to your database directly, so it has to be reachable from VERISCO. Connector mode removes that requirement. |
The same in every mode#
These happen on the sign-in page, which all three modes share:
- multi-factor authentication, captcha, password rules and lockout;
- network policy and IP blocking at sign-in;
- licence enforcement;
- your users staying in your own directory.
How fast a change arrives#
| Change made in your console | Gateway and connector | SDK |
|---|---|---|
| Ending a session, sealing a path, a policy or licence change | Within 5 seconds | Within 30 seconds |
Choosing#
| If | Choose |
|---|---|
| Your application is reachable from the internet | Gateway |
| Your application or your database is on a private network | Connector |
| You cannot put anything in front of your application, and it runs on Express or Connect | SDK |
| You run WordPress | Gateway or connector |
| Your application is not written in Node | Gateway or connector |
Changing mode#
Ask us. Moving between gateway and connector changes only how VERISCO reaches you: your integration code does not change at all. Moving to or from SDK mode does change your code, because the contract moves from "verify a header" to "be the sign-in client".
Something missing or wrong on this page? Tell us and we will fix it.