Connector mode

When to use it#

Your application, your user database, or both are on a private network. This is the common case.

Every control works exactly as in gateway mode, and the integration code is identical: the same middleware, the same X-Verisco-Claims header, the same public key. The only thing that changes is how VERISCO reaches you.

What you need#

• One machine in your network that can open outbound HTTPS connections on port 443.
• No inbound firewall rule. The agent dials out.

Install the agent#

Copy the install command from your onboarding page. It carries a ticket for your tenant, and there are two forms of it: one that installs a Linux service, one that runs a container.

You give VERISCO your application's local address, as seen from the machine running the agent, for example localhost:3000.

The agent reconnects by itself after a reboot or a network drop.

Tunnel your database too#

The same tunnel can carry your user database, so it stays on your private network. Choose Through the connector when you set up your identity source.

A tunnelled directory has to be proven once before your tenant can go live, because sign-ins cannot work until it answers. Use Test my user directory on your onboarding page.

If the agent stops#

VERISCO cannot reach your application. Sign-ins still work; your site is unreachable until the agent reconnects. VERISCO raises an alert within a minute.

systemctl status verisco-connector    # installed as a service
docker logs verisco-connector         # running as a container

Credentials#

The agent authenticates with a credential issued to your tenant. You can rotate it or revoke it from your console.

Then integrate#

The steps are the gateway's. Continue with Gateway mode: what your application does.