FoxIDs inside
FoxIDs is organised as a multi-tenant identity platform. Administrative configuration, operational identities and protocol endpoints are separated into explicit scopes, allowing one deployment to host many organisations and many independent identity providers.
Platform hierarchy
The hierarchy separates platform administration from tenant administration and operational identity configuration.
| Scope | Purpose | Contains |
|---|---|---|
| Platform master tenant | Administers the FoxIDs deployment | The platform master environment, FoxIDs administrator users and platform-wide configuration |
| Tenant | Isolates an organisation or customer | A tenant master environment and any number of regular environments |
| Tenant master environment | Administers one tenant | Tenant-specific master configuration and tenant administrator users |
| Environment | Operates as an independent Identity Provider | Endpoints, a user repository, certificates, authentication methods, application registrations and environment settings |
Operators of shared cloud deployments can also define plans in the platform master tenant to associate pricing and included usage with tenants for processing in an external billing system.
Regular environments are intended for operational users and integrations. The master environments remain administration boundaries and should not be used as substitutes for development, test or production environments.
Environment isolation
Each environment has a unique technical name that forms part of its endpoints. Configuration and runtime identity data are scoped to that environment.
This means that:
- A user in one environment does not automatically exist in another.
- Certificates, password policies, claim mappings, user-facing texts and access structures are environment-specific.
- Authentication methods define upstream identity providers and local sign-in options for the environment.
- Application registrations define the applications and APIs that trust the environment.
- Trust between environments exists only when an Environment Link or OpenID Connect connection is configured explicitly.
FoxIDs supports unlimited tenants, unlimited environments per tenant and unlimited users per environment. Practical capacity depends on the deployment resources and data store.
Configuration areas
Continue with the area that matches what you want to configure:
- Environments and certificates: Environments, Certificates
- Users and directories: Users, Internal users, External users, Directory Connector, Directory Connector for AD, Upload many users
- Access and claims: Access structure, Claims, Claim transforms and tasks
- User experience and messaging: Extended UI, Email provider, SMS provider
- Operations and administration: Logging, FoxIDs Control Client and API
Request path through FoxIDs
FoxIDs resolves the tenant and environment from the request URL before processing an authentication or token request. Within the selected environment:
- The application registration validates the incoming application or API request.
- FoxIDs selects an allowed authentication method, either directly or through home realm discovery.
- The authentication method signs in the user locally or delegates authentication to an upstream identity provider.
- Claims are normalised, mapped and transformed inside FoxIDs.
- The application receives the response in its configured protocol, allowing FoxIDs to bridge protocols when the two sides differ.
The application and authentication method therefore remain independently configurable while FoxIDs handles routing, claims and protocol translation between them.
Technical limits
FoxIDs applies maximum lengths to externally supplied protocol values to protect memory, storage and request processing. Depending on the value and protocol, oversized data is rejected or truncated.
URLs
- A URL can contain at most 10,240 characters.
- A query string can contain at most 10,240 characters.
Claims
- A JWT claim type can contain at most 80 characters.
- A SAML 2.0 claim type can contain at most 300 characters.
- The maximum processed length for an individual claim value and for combined claim values is 200,000 characters. Oversized claim values in received tokens are truncated.
If a JWT is carried as a claim value, it is subject to the same claim-value limit.
Tokens and SAML messages
- A JWT received by FoxIDs, including an access token, ID token or refresh token, can contain at most 256,000 characters.
- FoxIDs can issue a larger JWT because individual claims are capped instead of the complete generated token being truncated.
- A SAML 2.0 request or response can contain at most 256,000 characters.
- A SAML message using HTTP Redirect binding is also constrained by the URL and query-string limits.