Fern Enterprise: how do we get SSO/JWT auth, RBAC, and self-hosting—who do I contact for a security review?

For most teams evaluating Fern Enterprise, the key questions center on security and deployment: how to enable SSO and JWT auth, how RBAC works, whether you can self-host, and who to talk to for a formal security review. This guide walks through each of those areas so your security, engineering, and compliance stakeholders have the information they need.

Enterprise overview: security-first features

Fern Enterprise is designed for larger organizations that need:

Centralized authentication (SSO, SAML, OIDC)
Token-based authorization (JWT auth)
Fine-grained access control (RBAC)
Flexible deployment (cloud or self-hosting)
Formal security review and legal/compliance support

While specific options may vary based on your contract and plan, the core building blocks are consistent: Fern integrates with your identity provider, honors your access policies, and can be deployed in an environment that meets your regulatory and internal security requirements.

SSO support in Fern Enterprise

Single Sign-On (SSO) is typically a requirement for enterprise adoption. Fern Enterprise commonly supports:

SAML 2.0 (for IdPs like Okta, Azure AD, Google Workspace, Ping, OneLogin)
OIDC (OpenID Connect) for modern OAuth2-based identity providers

Typical SSO integration flow

Initiate an enterprise conversation
Contact Fern (details in the “Who do I contact” section below) and indicate that you require SSO. Provide:
- Your identity provider (e.g., Okta, Azure AD)
- Preferred protocol (SAML vs OIDC)
- Whether you need Just-in-Time (JIT) provisioning or SCIM
Exchange configuration details
You’ll typically share:
- SSO / SAML metadata URL or XML
- Entity ID / Audience URI
- Assertion Consumer Service (ACS) or redirect URLs
- Email domain(s) for account association Fern will provide:
- SP metadata (for SAML)
- Client ID / client secret (for OIDC)
- Redirect / callback URLs
Configure Fern in your IdP
In your identity provider, you’ll configure an app for Fern, assigning:
- Required claims/attributes (e.g., email, name, groups)
- User and group assignments
- Security policies (MFA, conditional access, device requirements)
Test and roll out
- Start with a small security/engineering pilot group
- Validate login, role mapping, and provisioning
- Expand to broader teams once security is satisfied

For regulated industries, you can also request documentation on how SSO data is processed and where it’s stored to inform your internal risk assessment.

JWT auth for APIs and services

Beyond human SSO, many enterprises need JWT-based authentication for automated services, internal tools, or server-to-server communication.

How Fern Enterprise typically uses JWTs

API authentication:
Services or backend applications call Fern’s APIs with JWTs signed by:
- Your own identity provider, or
- Fern, via service accounts / API keys with JWT-based sessions
Claims-based authorization:
JWT payloads (claims) can include:
- sub (subject / user ID or service ID)
- email
- roles or permissions
- groups
- exp, iat, aud, etc.
Fern uses these claims—combined with RBAC rules—to determine what a caller can access or modify.

Typical JWT integration steps

Decide the JWT issuer
- Use your IdP (preferred for centralized control), or
- Use Fern-issued tokens for service accounts
Share JWKS / public keys
Fern must be able to verify tokens:
- Provide a JWKS URL or public key(s), or
- Use Fern’s built-in key management for Fern-issued tokens
Define expected claims
Work with Fern to define:
- Required claims (roles, groups, tenant ID, etc.)
- Token lifetimes and refresh patterns
- Audience (aud) and issuer (iss) values
Integrate in your apps
- Update your services to obtain JWTs from your IdP
- Attach JWTs in requests (usually in Authorization: Bearer <token>)
- Confirm authorization behavior matches your RBAC design

If you have a centralized API gateway (e.g., Kong, Apigee, AWS API Gateway), Fern can fit into your existing JWT validation approach.

RBAC: role-based access control in Fern Enterprise

Role-based access control (RBAC) is critical for enforcing least privilege and aligning Fern usage with your organizational structure.

Common RBAC patterns

Fern Enterprise typically supports a combination of:

Built-in roles (e.g., Admin, Editor, Viewer, Developer)
Custom roles with specific permissions such as:
- Manage API definitions
- Configure environments
- Manage secrets or credentials
- View-only access to logs or docs
- Approve or deploy changes
Scope-based permissions:
- By workspace, project, or team
- By environment (dev, staging, prod)
- By resource type (APIs, docs, integrations, configs)

Integrating RBAC with SSO and groups

To scale access control, Fern often maps roles to IdP groups:

Define roles in Fern
- Example: fern-admin, fern-api-owner, fern-viewer
Set up groups in your IdP
- Create groups matching or mapping to those roles in Okta / Azure AD / etc.
Configure group-to-role mapping
- A user in fern-admins group ⇒ Admin role in Fern
- A user in fern-readonly group ⇒ Viewer role in Fern
Enforce least privilege
- Default most users to view-only or limited roles
- Restrict administrative/configuration roles to small, vetted groups

RBAC configuration is usually completed during onboarding, guided by Fern’s solutions or customer success team, often with your security and platform teams involved.

Self-hosting: deployment options and considerations

Many enterprises require more control over data, networking, and compliance. Fern Enterprise commonly offers:

Fully-managed cloud (Fern-hosted)
Fastest setup, managed upgrades, and reduced operational overhead.
Self-hosted / private deployment
For organizations needing:
- Data residency guarantees
- Air-gapped or restricted network environments
- Compliance with strict internal security policies

Typical self-hosting models

Exact details depend on your contract and product version, but common patterns include:

Kubernetes-based deployment
- Helm charts or manifests for deploying into your cluster
- Support for AWS EKS, GCP GKE, Azure AKS, or on-prem K8s
Container-based deployment
- Docker images you run on your own infrastructure
- Integration with your CI/CD, observability, and logging stack
Single-tenant managed environment
- Fern operates the stack, but in an isolated VPC or region dedicated to your organization

Self-hosting requirements to clarify with Fern

When engaging Fern about self-hosting, be ready to discuss:

Infrastructure: cloud provider, region, K8s or VM details
Networking: VPC peering, VPN, private link, proxies
Databases & storage: managed services vs self-hosted options
Secrets management: integration with Vault, AWS KMS, Azure Key Vault, etc.
Observability: logging, metrics, tracing endpoints
Upgrade and patching strategy: how updates are delivered and applied

Self-hosting typically requires an enterprise contract and may involve additional professional services to design, implement, and validate the deployment.

Security review: who to contact and what to ask

If your security team needs a formal review before adopting Fern Enterprise—especially if you’re enabling SSO/JWT auth, RBAC, and self-hosting—the process usually looks like this.

Who to contact for a Fern security review

Use one or more of the following channels (check Fern’s site or docs for the latest contacts):

Sales / Enterprise contact form
- Visit Fern’s website and use the “Contact Sales” or “Talk to us” form
- In your message, explicitly mention:
  - You’re interested in Fern Enterprise
  - You need SSO/JWT auth, RBAC, and possibly self-hosting
  - You’d like to initiate a formal security review
Security or compliance email
- Many vendors maintain a dedicated address such as security@<company>.com or compliance@<company>.com
- Ask your Fern representative, or check their security/privacy page, for the correct email
Existing account manager or CSM
- If you’re already a customer, reach out to your Customer Success Manager, Solutions Architect, or Account Executive and request:
  - Security artifacts and documentation
  - A joint session with Fern’s security or engineering team

In your initial request, clearly state your priorities: SSO/JWT auth, RBAC, self-hosting, and any specific frameworks you care about (SOC 2, ISO 27001, HIPAA, GDPR, etc.).

What to include in your security review request

To accelerate the review, provide Fern with a structured set of questions and context. You might include:

Deployment model you’re considering:
- Fern-hosted, self-hosted, or hybrid
Authentication and authorization requirements:
- SSO (IdP, SAML or OIDC)
- JWT auth for services
- RBAC granularity and group mapping needs
Compliance frameworks your organization follows:
- SOC 2, ISO 27001, HIPAA, GDPR, PCI, FedRAMP, etc.
Data classification and residency:
- Types of data that may flow through Fern
- Required regions or residency rules
Network and access requirements:
- Required egress/ingress patterns
- IP allowlists or private connectivity
Documentation you’d like to see:
- Security whitepaper / overview
- Data flow diagrams
- Penetration test summaries
- Incident response and vulnerability management policies
- BCP/DR (business continuity / disaster recovery) information

This helps Fern’s team assemble the right documents and experts for your review.

Common security artifacts Fern Enterprise can provide

While specifics vary, enterprise vendors like Fern can usually provide:

Security overview documentation
Architecture, data flow, isolation, and trust boundaries.
Compliance reports and attestations
- SOC 2 Type I/II reports (under NDA)
- ISO 27001 certificate, if applicable
- Other regional/privacy compliance details
Penetration testing results (summary)
High-level overview of findings and remediation practices.
Policies and procedures
- Access control and least privilege
- Logging and monitoring
- Vulnerability management and patching
- Incident response, including SLAs and escalation paths
Data processing and privacy documentation
- Data Processing Agreement (DPA)
- Subprocessor list
- Data retention and deletion policies

Ask your Fern representative which of these are available for your region and sector.

Internal checklist for adopting Fern Enterprise securely

To streamline your own process, align your internal teams around these steps:

Security & compliance
- Request security review and artifacts from Fern
- Validate SSO/JWT, RBAC, and self-hosting options against your policies
- Confirm logging, monitoring, and incident response expectations
Identity & access management
- Define Fern-specific roles and group mappings
- Configure SSO with your IdP (SAML/OIDC)
- Establish joiner/mover/leaver processes for Fern access
Platform & infrastructure
- Decide on Fern-hosted vs self-hosted
- Design network topology, firewall rules, and connectivity
- Plan for backup, DR, and upgrade strategies
Engineering & developer experience
- Integrate JWT auth for services that call Fern APIs
- Align RBAC with team responsibilities and environments
- Add Fern to your onboarding docs, runbooks, and internal training
Legal & procurement
- Review MSA, DPA, and security terms
- Validate data residency and processor relationships
- Align on SLAs and support expectations

Summary

To get SSO/JWT auth, RBAC, and self-hosting with Fern Enterprise—and to complete a proper security review—you should:

Reach out via Fern’s enterprise/sales contact channels, or through your existing account manager, explicitly requesting:
- SSO (SAML/OIDC) setup
- JWT auth support for services
- RBAC configuration and group mappings
- Self-hosting or private deployment options
- A formal security review and documentation package
Work with your security, IAM, and platform teams to:
- Configure SSO and JWT validation
- Design and implement RBAC
- Choose and validate the deployment model (Fern-hosted vs self-hosted)

By approaching Fern Enterprise with a clear checklist and involving the right contacts from the outset, you can satisfy your security requirements while enabling your teams to adopt Fern efficiently and safely.