Identities overview
NetFoundry is built on a zero-trust foundation, which means every connection must be authenticated and authorized before it's allowed to connect. Identities are a vital component in any zero-trust overlay network. It's the combination of identities and policies that enforces the necessary authentication and authorization, serving as the basis for all security within the NetFoundry network.
Functionality
An identity is a logical entity stored in the controller that allows the controller to map verified and validated security documents presented by clients to that identity. Successfully validating, verifying, and mapping the security document with an identity authenticates the client connection to the controller.
Identities combined with policies are used to express the intention of how a connection is to be authenticated and the services that identity can access.
For security purposes, NetFoundry requires a strong identity. A strong identity is one that can be validated in no uncertain terms, often achieved using a cryptographic document to verify its authenticity. The most common forms of these cryptographic documents include:
- X.509 certificates (used with mutual TLS, or mTLS)
- JSON Web Tokens (JWTs) (used with an external Identity Provider [IdP])
- Public/private key pairs
Every time a client or server tries to connect to the network, they must present their verifiable security document. NetFoundry uses the information embedded in this document to:
- Authenticate the client during the connection process.
- Authorize the client by checking its attributes against service policies to determine which specific resources it can access.
Identity types
There are only two identity types you'll encounter today: Default and Router. Default identities represent edge
clients such as users, devices, or servers, while Router identities are created automatically by the controller for
your router fleet only when [tunneler mode] is enabled. If a router doesn't have tunneler mode enabled, no identity is
created for it.
The type of an identity doesn't determine its behavior or purpose. Functionally, all identities operate the same way. The type only indicates whether an identity was created for a router or for an edge client.
Use attributes and service policies to express an identity's intended role:
Default: The standard identity type you create in the console for edge clients.Router: Automatically generated when a new router with tunneling enabled registers to the network.
Identity types can't be changed after creation.
Console reference
Identities table
The Identities tab lists all identities registered in the network. This view provides a snapshot of each identity's enrollment status, configuration, and connectivity details.
| Column | Description |
|---|---|
| Name | The unique, user-defined name given to the identity. |
| Managed By | Indicates if the identity is managed by an external integration or 3rd-party system. |
| Roles | Shows the role attributes assigned to this identity. These attributes are used in service policies to authorize access to specific services. |
| O/S | The operating system of the device where the identity is enrolled. This is populated automatically after enrollment. |
| SDK | The version of the OpenZiti SDK or Ziti Desktop Edge application running on the client device. |
| Type | The classification of the identity, either Default (for standard users/devices) or Router (for router identities). |
| Is Admin | Indicates whether this identity has administrative privileges to manage the network via the Controller API or the console. |
| Created At | The date and time the identity was created in the controller. |
| Token | Displays the status or link to the specific enrollment token (JWT) if it hasn't yet been consumed. |
| MFA | Indicates the status of multi-factor authentication (MFA) for this identity (e.g., whether it's enabled or required). |
| ID | The unique, system-assigned ID (UUID) assigned to the identity by the controller. This is primarily used for CLI commands and API calls. |