Bondy Connect

Appearance

Security ​

Bondy enforces security at the router, before a message ever reaches a procedure or a subscriber — not as something each application has to implement itself. Two independent questions get answered on every session and every call: who is this (authentication), and is this identity allowed to do what it's asking (authorization), scoped to the realm the session is attached to.

Multi-tenancy ​

Realms ​

A realm is the boundary both questions are asked within: authentication credentials, RBAC rules, and message routing are all scoped to one realm, and nothing routed in one realm leaks into another. A user, group, or grant defined in one realm doesn't exist in a different one — the same username can mean two different identities with two different permission sets in two different realms, and Bondy never conflates them.

This is what makes a single Bondy cluster able to serve multiple, mutually isolated tenants: each realm is a self-contained security domain, and creating one costs nothing beyond the control-plane record itself — see Realms for the full model, including the Master Realm that administers every other realm, and Same Sign-On / Single Sign-On for the two ways Bondy lets one identity span several realms without duplicating credentials in each.

Authentication ​

Authentication establishes who a session belongs to. A realm doesn't pick one method — it allows a set of them, and a connecting client chooses which one to use, so a browser session using cryptosign and a service session using wampcra can coexist on the same realm.

Using anonymous ​

No credentials at all; the session is assigned to the anonymous group. Useful for public, unauthenticated access, but the resulting session still goes through authorization — the anonymous group's permissions are ordinary RBAC grants, not a bypass.

Using cryptosign ​

Public-key challenge-response: the client signs a server-issued challenge with an Ed25519 private key, and Bondy verifies it against the user's registered public key. No secret crosses the wire in either direction.

Using wampcra ​

Shared-secret challenge-response: Bondy issues a challenge, the client returns an HMAC of it keyed by a secret derived from the user's password. The password itself never crosses the wire, but (unlike cryptosign) both sides must hold the same shared secret.

Using wamp-scram ​

An adaptation of SCRAM (RFC 5802) to WAMP. Like wampcra, the password never crosses the wire; SCRAM additionally adds mutual authentication and per-session salting and iteration counts, resisting precomputed-hash attacks that a static HMAC challenge doesn't.

Using ticket ​

A previously issued ticket, presented alongside a username, in place of a password or key. Tickets are how a session that already authenticated once (via one of the methods above) can reauthenticate cheaply — see the Ticket WAMP API Reference for issuing and using them.

Bondy also supports password (clear-text, TLS-dependent), trust (accepts an existing username with no credential check, meant to be paired with a network-restricted source), and oauth2 (token-based, via the HTTP Gateway). See the glossary's Authentication Method entry for the full list in one place, and Security Configuration Reference for configuring which methods a realm allows.

Refusing an unknown user ​

Bondy's answer to a HELLO does not tell a client whether a user exists. Some refusals depend on the user:

  • the user is unknown or disabled;
  • the user does not hold the requested role;
  • no source allows the requested methods for the user.

For these, Bondy answers as it does for a real user. When the client asks for wampcra or wamp-scram and the realm enables that method, Bondy sends a challenge that no response can satisfy. Every node sends the same salt for the same authid, as it does for a stored user. When the client asks only for other methods the realm enables, Bondy sends the ABORT it sends for a wrong credential: wamp.error.authentication_failed. Bondy logs the actual reason.

A HELLO that names no method the realm enables gets the same refusal for every user, so that refusal keeps its specific error.

Authorization ​

Authentication answers who; authorization answers what they can do. Bondy's authorization model is Role-Based Access Control (RBAC): permissions are granted to a role — a user or a group — not to a session directly, and a session inherits whatever its authenticated user (and that user's groups, transitively) has been granted.

RBAC model ​

A permission check asks one question: does this session's role hold the requested action on the requested resource? Concretely:

  • Users are the identities that authenticate. See the User WAMP API Reference.
  • Groups are named collections of users (and other groups). Granting a permission to a group grants it to every member, transitively — the mechanism Simplifying Realm Management with Prototypes builds on to keep large realms manageable. See the Group WAMP API Reference.
  • Grants bind a set of actions (wamp.call, wamp.register, wamp.publish, and the other WAMP permission actions) to a resource — a procedure or topic URI, matched exact, prefix, or wildcard — for a role. A grant on the resource any applies regardless of the resource requested. See the Grant WAMP API Reference.
  • Sources restrict how a user may authenticate at all, independent of what they're authorized to do once they have: a source binds a username (or all) to an allowed authentication method and a CIDR range, so a credential that's valid in principle still can't be used to open a session from a network it isn't trusted on. See the Source WAMP API Reference.

Authorization changes reach sessions that are already open. Bondy authorizes each session against a cached context: the session's grants, with everything it inherits through its groups already resolved. Changing a grant, or a group's parent groups, invalidates the cached contexts in the realm, and each session re-resolves its context on its next authorization. Bondy also rebuilds any cached context older than five minutes. A change to a user's group membership invalidates the tokens issued to that user before the change. Authentication changes are different: changing a user's credentials, or deleting the user, closes the user's sessions.

Security can be turned off per realm

A realm's RBAC checks can be disabled entirely (bondy.realm.security.disable — see the Realm WAMP API Reference), which makes every authorization check pass unconditionally. This is meant for development, not production: users, groups, and grants stay fully configurable while security is disabled, and take effect again the moment it's re-enabled.

See also ​