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

For teams evaluating Fern Enterprise, questions about SSO, JWT-based authentication, RBAC, and self-hosting usually come up at the same time as security and compliance reviews. This guide walks through what is typically available in Fern Enterprise, how to request these features, and who to contact for a security review so you can move quickly while staying aligned with your organization’s security standards.

Overview of Fern Enterprise capabilities

Fern Enterprise is designed for larger engineering and platform teams that need stronger security, governance, and deployment flexibility than what’s typically available in a standard cloud offering. In most cases, Fern Enterprise includes:

Enterprise authentication and SSO (SAML / OIDC)
JWT-based auth integration for your services
Role-Based Access Control (RBAC) for granular permissions
Options for self-hosting or private deployment models
Formal security and compliance documentation and review support

Exact features and deployment modes can depend on your agreement and the version of the platform, so you should confirm details with the Fern sales or solutions engineering team.

SSO in Fern Enterprise

Single Sign-On (SSO) is usually one of the first requirements for enterprise adoption. In a typical Fern Enterprise setup, SSO is supported via standards-based identity protocols so you can integrate with your existing IdP.

Common SSO integrations

Fern Enterprise generally supports integration with major identity providers, for example:

Okta
Azure AD / Entra ID
Google Workspace / Google Identity
OneLogin
Ping Identity

The integration is usually done via:

SAML 2.0: Widely used in enterprise SSO environments
OIDC / OAuth 2.0: Common in more modern identity setups

How SSO is typically enabled

Although exact steps depend on your contract and deployment model, the usual process looks like this:

Contact Fern sales or support
Let them know you’re interested in Fern Enterprise with SSO. They’ll confirm your plan and enable enterprise auth configuration for your organization.
Share IdP details
You provide:
- Identity provider (Okta, Azure AD, etc.)
- Desired authentication protocol (SAML or OIDC)
- Metadata or configuration (SAML metadata XML, redirect URIs, client ID/secret, etc.)
Configure SSO in your IdP
In your IdP, you:
- Create an enterprise application for Fern
- Configure assertion/claims (email, name, groups if used for RBAC)
- Set sign-on URL, ACS/redirect URL, and audience/Entity ID according to Fern’s documentation
Test and roll out
Your security, IT, or platform team tests:
- Login flows (IdP-initiated and SP-initiated, if applicable)
- User provisioning and deprovisioning behavior
- Group-based access, if used for RBAC

For the exact SSO documentation and configuration details, you’ll need to request Fern’s enterprise integration guide from their team.

JWT auth for your APIs and services

When teams ask about “SSO/JWT auth” for Fern Enterprise, they often mean two related pieces:

How users authenticate into Fern (SSO)
How Fern integrates with JWT-based authentication for your own APIs and services

JWT support in typical Fern Enterprise setups

In most enterprise environments, Fern can:

Generate or validate JWTs as part of API access workflows
Integrate with your existing identity provider or auth server
Respect your signing algorithms (e.g., RS256, ES256) and key management setup
Forward identities and claims (e.g., sub, email, groups) through to your backend services or API gateway

Common integration patterns include:

Fern as a client of your IdP
Fern redirects users to your IdP for sign-in, then uses returned tokens (ID token / access token) and passes them through to your services where appropriate.
JWT validation for upstream calls
Fern validates JWTs on behalf of your backend services or infrastructure, based on keys retrieved from your JWKS endpoint or configured public keys.
Custom claim mapping
Claims like roles, groups, or tenant_id can be mapped to Fern’s internal roles and permissions (for RBAC) or forwarded to your API layer.

To implement JWT auth correctly, your security or platform team will usually want:

Fern’s JWT validation/handling documentation
Details on how Fern stores or caches tokens (if applicable)
Information about how Fern secures secrets, keys, and environment variables

You can obtain these details by requesting Fern’s enterprise technical docs or by scheduling a session with a Fern solutions engineer.

RBAC in Fern Enterprise

Role-Based Access Control is critical for teams that need least-privilege access, separation of duties, and auditability across large organizations.

Typical RBAC capabilities

Fern Enterprise usually supports:

Organization-level roles: Admin, Owner, Member, Read-only, etc.
Project or workspace-level roles: Granular permissions per project, service, or API.
Permission scopes: Control over actions like:
- Creating or modifying API definitions
- Managing environments and deployments
- Accessing secrets or credentials
- Managing integrations and configurations
Group-based roles: Integration with IdP groups so you can assign roles based on your existing group structure.

How RBAC is typically configured

Configuration commonly follows this pattern:

Define roles and responsibilities
Your team decides:
- Who should be admins
- Which teams can create or edit APIs
- Which teams should have read-only access
Connect groups from your IdP
If Fern supports SCIM or group sync, your security/IT team:
- Maps identity provider groups (e.g., fern-admins, backend-team) to Fern roles.
- Optionally sets default roles or access levels for new users.
Apply project-level permissions
Admins or project owners:
- Assign roles per workspace or API
- Restrict sensitive actions to a smaller group of trusted users
Review and audit
For compliance, you may periodically review:
- Who has which roles
- Activity logs related to configuration changes, deployments, or access

You can request Fern’s RBAC model documentation from their enterprise team to confirm which permissions and roles are available in your version.

Self-hosting and deployment options

Many enterprises need stricter control over data residency, network boundaries, and infrastructure. Fern Enterprise often supports deployment models beyond standard multi-tenant cloud.

Common deployment models

Typical options include:

Fully managed SaaS (standard)
Fastest to adopt, managed by Fern. Enterprise features like SSO and RBAC still apply, but infrastructure is hosted by Fern in their cloud.
Single-tenant / dedicated environment
A dedicated instance of Fern managed by Fern but isolated at the infrastructure level. Often used for stricter isolation or data residency requirements.
Self-hosted / private deployment
Running Fern within your own:
- Kubernetes cluster
- Private cloud (AWS, GCP, Azure)
- On-premises environment (if supported)

In a self-hosted model, your team manages:

Infrastructure and scaling
Network and access controls
Integration with internal tooling (logging, monitoring, SIEM)
Backup, recovery, and change management processes

Fern typically provides:

Docker images or Helm charts
Infrastructure requirements and reference architectures
Upgrades and maintenance guidelines
Security and configuration best practices

The exact self-hosting path depends on your environment, so you’ll need to coordinate directly with Fern’s engineering or solutions team.

Security review: who to contact and what to request

If you’re asking “who do I contact for a security review?” you’re likely at the stage where legal, security, or procurement needs to evaluate Fern Enterprise.

Primary contacts for security review

You should reach out to:

Your existing Fern point of contact
- Account executive, sales rep, or customer success manager, if you already have one.
- They can coordinate security review resources and documentation.
Fern enterprise sales
- If you don’t have a contact yet, use the “Contact Sales” or “Enterprise” form on Fern’s website.
- In your message, mention that you need:
  - SSO/JWT auth
  - RBAC
  - Self-hosting / private deployment
  - A formal security review
Fern support or general contact
- If there’s a generic support or contact email, you can request:
  - “Enterprise security and compliance documentation”
  - “Technical architecture and data flow details”
  - “Security review call with a solutions engineer”

Depending on Fern’s setup, you may also be connected with a dedicated security or compliance contact.

What to ask for during a security review

To streamline your evaluation, you can explicitly request:

Security documentation
- Security whitepaper or overview
- Infrastructure and architecture diagrams
- Data flow diagrams (including auth and token handling)
- Encryption details (in transit and at rest)
- Key management and secrets management practices
Compliance and policy information
- SOC 2 / ISO 27001 / other certifications (if applicable)
- Privacy policy and data processing agreements
- Data residency options and data retention policies
- Incident response processes and SLAs
Enterprise features and configuration details
- SSO integration guide (SAML/OIDC)
- JWT handling and configuration documentation
- RBAC model and permission matrix
- Self-hosting or private deployment guide
Security Q&A and questionnaires
- Vendor security questionnaire support (SIG, CAIQ, or custom)
- Clarification on logging, audit trails, and monitoring
- Penetration testing and third-party assessment summaries, if available

Providing your internal security checklist or questionnaire in advance will help Fern’s team give you more targeted answers.

Typical implementation sequence for enterprises

If you’re planning a rollout, the following sequence tends to work well:

Initial evaluation
- Confirm Fern Enterprise includes SSO/JWT, RBAC, and the deployment model you need (SaaS, dedicated, or self-hosted).
- Review basic architecture and feature set with a Fern solutions engineer.
Security and compliance review
- Share your security requirements and questionnaires.
- Review Fern’s security documentation and deployment architecture.
- Confirm data residency, logging, and access control capabilities.
SSO and RBAC setup
- Configure Fern SSO with your IdP (SAML/OIDC).
- Map groups and roles to align with your org structure.
- Pilot with a small team to verify access behavior.
JWT and API integration
- Integrate Fern with your identity provider or auth server.
- Configure JWT validation, claim mapping, and any upstream token forwarding.
- Verify that your backend services receive the identity and authorization context they require.
Self-hosting or environment setup (if applicable)
- Deploy Fern into your own infrastructure or dedicated environment.
- Integrate with your logging, monitoring, and security tooling.
- Run staging tests and security validation before production cutover.
Full rollout
- Train internal teams on access patterns and RBAC.
- Enable SSO organization-wide.
- Implement ongoing access reviews and audits.

How to move forward

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

Reach out to your Fern sales or account contact (or use the enterprise/contact form on Fern’s website).
Explicitly state your requirements, for example:
“We’re evaluating Fern Enterprise and need SSO/JWT authentication, RBAC, and self-hosting options, plus a formal security and compliance review.”
Request security and technical documentation, including:
- SSO and JWT integration guides
- RBAC/permissions documentation
- Self-hosted or dedicated deployment reference architecture
- Security and compliance overview (plus any available certifications)
Schedule a security review call with Fern’s security or solutions engineering team to walk through your organization’s specific requirements.

By coordinating directly with Fern’s enterprise and security teams, you can confirm that SSO, JWT auth, RBAC, and self-hosting are configured in a way that aligns with your internal policies and compliance obligations.