Security

Enterprise Studio delegates authentication to Neo4j and does not store credentials or maintain server-side sessions. This page covers authentication, authorization, TLS encryption, secrets management, and content security.

Authentication

Enterprise Studio does not maintain its own user database. Authentication is delegated to the connected Neo4j deployments, and every API request is independently verified.

Basic authentication

Users sign in with a Neo4j username and password. Enterprise Studio forwards the credentials to Neo4j with each request and verifies the user’s identity and roles.

SSO / OIDC (bearer token)

When Neo4j is configured with an OIDC identity provider, users authenticate through the IdP in the browser. The resulting bearer token is sent to Enterprise Studio in the Authorization: Bearer <token> header, and Enterprise Studio passes it directly to Neo4j for verification. Enterprise Studio does not validate the JWT itself.

Enterprise Studio has no SSO configuration of its own — it relies entirely on Neo4j’s OIDC support. To enable SSO, configure your Neo4j deployment(s) to trust an identity provider and map IdP group claims to database roles. See Operations Manual → Configuring Neo4j Single-Sign-On (SSO) for the full walkthrough.

Once Neo4j maps IdP groups to database roles, Enterprise Studio maps those database roles to Enterprise Studio roles via authorization.roleMapping. See Administration → Assigning roles with SSO for configuration examples.

To enable per-user asset sharing with SSO users, see Prerequisites → Configure SSO.

Authorization

Enterprise Studio maps Neo4j database roles to Enterprise Studio roles via authorization.roleMapping in config.yaml. There are two roles:

studioCreator: can create and manage their own assets.
studioAdmin: has administrative privileges over all assets.

When using SSO, the IdP’s group claims are mapped to Neo4j database roles, which are then mapped to Enterprise Studio roles through the same mechanism.

See Administration for details on user management, role mapping, and SSO role configuration.

TLS encryption

Enterprise Studio supports TLS to encrypt client-to-server communications. The server enforces a minimum of TLS 1.2.

Without TLS, user credentials and bearer tokens are sent unencrypted in HTTP headers with every request. Always enable TLS for production deployments.

Client-facing HTTPS

To enable HTTPS, provide a PEM-encoded X.509 certificate and an unencrypted PKCS #8 private key, then enable it in config.yaml.

Certificates must follow the X.509 standard and be PEM-encoded. Many browsers require Subject Alternative Names (SANs) on the certificate, not only the Common Name (CN). For local development, you can generate a self-signed key and certificate with SANs in one step:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out public.crt -days 365 -nodes \
  -subj "/CN=localhost" \
  -addext "subjectAltName=DNS:localhost,IP:127.0.0.1"

If your key is in legacy RSA format (BEGIN RSA PRIVATE KEY), convert it first:

openssl pkcs8 -topk8 -nocrypt -in legacy.key -out private.key

For more information on generating certificates and keys, see Operations Manual → Generating certificates and keys.

To verify a TLS connection after setup:

openssl s_client -connect <hostname>:<port>

The following examples show how to enable HTTPS for each deployment type.

Binary

Place the files in the certificate directory and configure config.yaml:

mkdir -p <enterprise-studio-home>/certificates/https
cp public.crt private.key <enterprise-studio-home>/certificates/https/
chmod 0400 <enterprise-studio-home>/certificates/https/private.key

server:
  https:
    enabled: true
    certificates:
      baseDirectory: certificates/https   # relative to install dir, or use an absolute path
      privateKey: private.key
      publicCertificate: public.crt        # include intermediate CA certs in this file if needed

Docker

Mount the certificate files into the container and enable HTTPS via environment variables:

docker run \
  -p 8080:8080 \
  -v /path/to/certs:/app/certificates/https:ro \
  -e NES_server_https_enabled="true" \
  europe-west1-docker.pkg.dev/dev-upx/enterprise-studio/neo4j-enterprise-studio

Kubernetes

TLS can be terminated at the Ingress controller or inside the pod. See Deploy to Kubernetes → Ingress and TLS for details.

Restart the server after any changes. Enterprise Studio reads TLS configuration only at startup and does not support hot-reload of certificates. See Reference for the full list of TLS settings.

Neo4j backend connections

Enterprise Studio connects to Neo4j for asset storage and, when query proxying is enabled (the default), for user queries. To encrypt these server-side connections, use TLS-enabled URI schemes:

Asset storage: use neo4j+s://, bolt+s://, or https://.
Proxied queries (default): the server proxies queries to Neo4j over HTTP. Use https:// for the deployment URI.

When directClientQuery.enabled is true, the browser connects to Neo4j directly and Enterprise Studio does not proxy queries. In that case, TLS for queries is between the browser and Neo4j, not managed by Enterprise Studio.

If your Neo4j deployment uses a private CA, Enterprise Studio must trust that CA. Deployments signed by public CAs (for example Neo4j Aura) require no extra trust steps. See the deployment-specific guides to install private CA certificates: Binary, Docker, Kubernetes.

Secrets management

Sensitive configuration values (passwords, client secrets) should be supplied via environment variables instead of storing them in config.yaml. See Deploy with Docker and Deploy to Kubernetes → Managing secrets for deployment-specific guidance.

Enterprise Studio automatically redacts sensitive fields in log output.

Enterprise Studio does not hot-reload configuration. A restart is required after changing any credential (asset storage password, SSO client secret, etc.). When running multiple replicas, a rolling restart applies the change with zero downtime.

Content-Security-Policy (CSP)

A default CSP is applied to all static frontend responses. You can customize or disable it via server.contentSecurityPolicyHeader in config.yaml. See Configuration reference → server.contentSecurityPolicyHeader for the default policy and override options.