Disabled authentication

Disable platform authentication entirely — the default configuration for local deployments and demo sandboxes where no security is required.

ODD Platform allows to disable authentication at all. This is useful when you want to deploy platform locally and don't need any security configured. This is the default configuration and no additional settings are required.

YAML

auth:
    type: DISABLED

Environment variables

AUTH_TYPE=DISABLED

DO NOT use this method in your production environment!

The rest of this page enumerates what an anonymous caller on the network can reach under auth.type: DISABLED. The intent is not to soften the warning above — it is to give operators the specific surface area so they understand the warning's scope.

What's anonymously reachable

The DISABLED-mode security configuration accepts every exchange (.anyExchange().permitAll()) — every HTTP endpoint on the platform is reachable to an unauthenticated caller. The surfaces below are the load-bearing ones an operator should know about before exposing a DISABLED-mode deployment on any network broader than localhost:

• GET /api/identity/whoami returns a synthetic admin identity: { "username": "admin", "permissions": [ … every Permission value defined on the platform … ] }. The permission set is built from Permission.values(), so any new platform capability added in a future release is automatically granted to this anonymous synthetic admin — there is no per-permission opt-in. Every UI control gated by a permission unlocks; every state-changing endpoint accepts mutations from any caller on the network.

• GET /api/appInfo returns the precise platform version (buildProperties.getVersion()) and the active auth.type value, with no authentication. The authType field shape is ODD-specific — a passive network scanner can confirm the deployment IS ODD Platform, learn its version (CVE-scoping), and learn the auth-mode value in one unauthenticated GET.

• GET /actuator/env returns the schema of configured properties — which OAuth2 providers are wired (the property-key prefixes), whether LDAP is configured, that a JDBC datasource is configured (the spring.datasource.url key, not its value). The actuator namespace /actuator/** is whitelisted in Spring Security in every auth mode (not just DISABLED), and the default management.endpoints.web.exposure.include setting includes env. Property values are masked (******) for every caller by default (show-values defaults to NEVER), but the property keys and sources are still informative for an attacker mapping the deployment.

• Every /api/** endpoint is reachable as a mutation surface. Owner CRUD, Policy / Role / Permission mutations, Lookup-table data row mutations, attachment uploads, custom-metadata writes, business-glossary term writes — every state-changing endpoint accepts requests with no auth. The platform's data integrity under DISABLED depends entirely on operator-side network isolation.

Fingerprint matrix (passive recon)

An unauthenticated caller can determine the platform's auth mode in one request by observing the response shape of GET /api/identity/whoami. The four mode-distinguishing responses:

auth.type	Response to anonymous GET /api/identity/whoami	What it tells the caller
DISABLED	200 OK + { "username": "admin", "permissions": [ ... ] }	Mode known; full admin reach to anonymous caller.
LOGIN_FORM	302 Found → /login	Mode known; credentials gating exists.
OAUTH2 / LDAP	401 Unauthorized	Mode known; OIDC / LDAP auth required.

DISABLED is the easiest mode to fingerprint anonymously on the network. The combination with GET /api/appInfo (which surfaces the auth-mode value directly) means an anonymous network scan can confirm-ODD + version + auth-mode + reach the admin endpoint in a handful of unauthenticated requests.

Reserved usernames

The DISABLED-mode synthetic identity uses the literal lowercase string admin; the S2S authentication filter uses the literal uppercase string ADMIN. The platform's user-to-owner mapping table compares names case-sensitively. Avoid provisioning operator-managed users with either of these literal names in LOGIN_FORM, LDAP, or any OAuth2 provider — a user named admin or ADMIN collides with the synthetic identities and inherits whatever owner mapping the synthetic principal resolves to. See the matching note on the Server-to-server (S2S) authentication page.

Migrating away from DISABLED

When you flip auth.type from DISABLED to LOGIN_FORM, OAUTH2, or LDAP, the synthetic-admin response from GET /api/identity/whoami vanishes — anonymous callers stop seeing the admin grant. For the cross-mode comparison of how each target mode grants ADMIN, see Admin promotion across providers. Before flipping, audit:

• Any existing Owner rows whose OIDC_USERNAME matches the literal admin or ADMIN — these will collide with the DISABLED synthetic identity (or with S2S — see S2S) once the platform starts attributing real user names through the real auth chain.

• Any RBAC Policy or Role you authored while running DISABLED — they were never consulted under DISABLED (every caller was admin), so they take effect for the first time when the migration completes; mis-configurations that were silent under DISABLED start to bite immediately.

• Network exposure that you tolerated under DISABLED on the assumption that the deployment was only-on-localhost — verify that the network boundary is still where you think it is before the synthetic admin disappears.