Product notes
Connecting without storing passwords
Your passwords already live in Active Directory. How do you add modern login without copying password hashes or publishing an inbound connector endpoint?
Start from what cannot change
Employee accounts are in Active Directory. So is the password policy, expiry, and the offboarding switch. It has been running for years.
You want passkeys on top. You want MFA rationalised. You want more SSO into SaaS. The goal is clear, and the first step always lands on the same question: where does password verification happen?
Some configurations sync password hashes to the cloud; others ask the internal directory to verify credentials. The useful questions are where credentials live, which side opens the connection, and who operates that route.
WordWarden keeps verification with LDAP/AD and lets you choose the route. Authrim Relay provides an outbound connection for organisations that do not want to publish a new inbound endpoint.
What WordWarden does
Authrim WordWarden is a directory connector. A small service you run next to your LDAP/AD, with one job: take a username and password, ask the directory, return the verdict.
Login UI, sessions, passkeys, email codes, federation output, audit correlation and identity mapping all stay on the Authrim side. WordWarden does verification only, next to the directory.
The direction of the connection changes the network configuration and the components you operate.
Who dials whom
WordWarden supports three transports. What separates them is whether your network has to publish a listener.
Which fits your environment?
For a new deployment that should not add inbound access, start by considering Relay. An existing publishing platform or tunnel can also be worth using. The following are deployment scenarios, not claims about customer deployments.
Authrim Relay: keep AD inside without adding inbound access
Consider a company running AD at its headquarters where each new public server requires a separate review, or a university that does not permit incoming connections to its campus LDAP network. WordWarden opens the connection to Authrim, so no new inbound port needs to be published on that network.
No new public endpoint or separate tunnel process is needed. Outbound WebSocket traffic must be allowed, and WordWarden's health and connection still need monitoring. Relay cannot serve a network that prohibits external communication altogether.
Cloudflare Tunnel: use an established tunnel operation
An organisation already publishing internal tools through Cloudflare Tunnel may have a team responsible for cloudflared updates and routing. WordWarden can fit those procedures without opening a new inbound port.
You configure the hostname and route that let requests from Authrim reach the connector, and maintain the tunnel. The internal host needs no direct inbound access, but requests arrive through a route on Cloudflare.
Direct HTTPS: use an existing public API platform
A company, university or research institution may already have an infrastructure team operating a DMZ and reverse proxy for external integrations. An HTTPS endpoint reachable from Authrim can use that team's existing certificate, access-log and monitoring procedures.
No separate tunnel or Relay connection needs to be maintained. In return, the organisation permits the inbound route and takes responsibility for protecting and maintaining the public endpoint. The published route is the connector's HTTPS interface, not the LDAP/AD port exposed directly to the internet.
Every method requires operating WordWarden where it can reach LDAP/AD. Being an academic institution does not determine the method; existing infrastructure and network policy do.
Authrim Relay — a connection that only leaves
In relay mode, WordWarden connects to Authrim using WebSocket from inside your network. WebSocket keeps a communication connection open so that either side can send messages over it.
WordWarden keeps that connection open and waits. When someone logs in, Authrim uses the same connection to ask, "Please verify this user." WordWarden checks with the internal directory and sends back the result.
Think of making a phone call from inside the organisation and staying on the line: the other person can speak too. There is no need for a new incoming connection for each request.
In practice that means the directory side publishes no URL at all. This avoids managing a hostname, certificate and WAF for a new public endpoint. Outbound permission, WordWarden maintenance and connection monitoring are still needed.
Technical detail: how WebSocket differs from publishing an inbound port
The difference is which side starts the connection. With Direct HTTPS, the organisation provides an endpoint that Authrim can connect to. With Relay, WordWarden inside the organisation opens an encrypted WebSocket connection (wss) to Authrim's Relay.
A typical stateful firewall or NAT tracks connections initiated from inside and allows their return traffic. This lets WordWarden receive verification requests without publishing an inbound port or configuring port forwarding for new external connections to it.
This does not mean that no ports are used. A typical wss connection uses TCP port 443 at the destination. The organisation's firewall or proxy must allow outbound access to Relay and sustained WebSocket connections. Requests cannot arrive over that route while it is disconnected, so connection monitoring still matters.
Reducing endpoints for new external connections does not remove the verification requests arriving over the established connection. Peer authentication and request validation remain necessary.
Reference: The WebSocket Protocol (RFC 6455)
An outbound connection still needs authentication. Relay combines connector authentication with checks on the configured destination.
Technical detail: authenticating with HMAC
WordWarden authenticates with an HMAC response to a short-lived challenge, signing a string containing the challenge ID and nonce. It also checks that the tenant and connector IDs in the destination URL match its configuration.
HMAC is required in all three transports. Relay reduces inbound exposure; it does not remove the need for connector authentication or secret management.
What actually crosses the boundary
Worth being exact here, because the loose version is wrong. It is not true that the password never leaves your network.
The user types it into a login screen, so it transits Authrim. The accurate claim is "Authrim and WordWarden do not store it" — not "it never leaves."
The return trip is narrowed too
On success, Authrim receives the verdict plus the requested attributes intersected with the connector's local allowlist. The requesting side does not decide what it can pull; the directory side decides what it will release.
That direction matters. No change on the Authrim side alone can widen what leaves your network.
The password is a bridge, not a destination
Positioned in one line: this integration exists for the transition.
Leave LDAP/AD as the password authority. Keep people signing in with the account they already have. Enroll passkeys underneath, progressively. Keep email code as the recovery path. From the user's side nothing breaks; the authentication method quietly changes out.
The documentation also states the prohibition plainly: do not export LDAP/AD password hashes into Authrim. Do that and the bridge becomes a credential copy.
Preparing for public beta. First target is v0.1.0-beta.1.
Intended for pilots — organisations that can run a small service near LDAP/AD and understand the directory, network, TLS and secret-management boundaries. It is not a managed directory service.
Requires Authrim 0.3.2 or later with Directory Authentication and Relay enabled. In the current beta, configuration changes need a process restart.
"Credentials out, or traffic in"
is not the only menu.
Verify next to the directory, and make the connection outbound-only. Satisfy both and you get modern login without copying password hashes and without publishing a listener inside your network.
And what sits on the far side is not continued password use — it is the move to passkeys. Directory integration is the footing that lets that migration proceed without stopping anyone from logging in.