Your identity provider is the trust anchor for every access decision in a Zero Trust model. When configured correctly, it determines who reaches which application, from which device, under which conditions. When misconfigured, it becomes the single point of failure that undermines your entire security posture.
This guide covers how identity providers work, how SSO protocols like SAML and OIDC fit into the picture, and how to connect your IdP to a Zero Trust Network Access layer. It is written for IT managers at European mid-market organisations who need practical integration steps, not theory.
How to connect your identity provider to Zero Trust access
- Choose an IdP that supports SAML 2.0 and OIDC, such as Microsoft Entra ID, Okta, or Google Workspace.
- Exchange metadata between your IdP and your ZTNA platform to establish the trust relationship.
- Map user groups and roles from your directory to application-level access policies.
- Enable device posture checks so access decisions combine identity with device health.
- Activate SCIM provisioning to keep user accounts synchronised automatically.
- Test with a pilot group, then enforce least-privilege policies across all applications.
What is an identity provider and why does it matter for access control
An identity provider (IdP) is the system that authenticates users and issues trusted tokens to the applications they need to reach. It is the single source of truth for who someone is, what groups they belong to, and whether their login meets your security requirements.
In practical terms, your IdP handles three things. It verifies credentials (passwords, MFA, biometrics). It maintains user attributes like roles, group memberships, and email addresses. And it issues cryptographically signed tokens that downstream applications trust without running their own authentication.
For IT teams managing 50 to 400 users across hybrid environments, the IdP is the one component that touches every access flow. Remote workers authenticating to internal apps, contractors requesting time-limited access, service accounts calling APIs: all of these pass through your identity provider first.
Common identity providers in European mid-market environments include Microsoft Entra ID (formerly Azure AD), Okta, Google Workspace, and Ping Identity. Each supports the federation protocols that Zero Trust access layers depend on.
The difference between an IdP and a service provider
The distinction matters when you configure integrations. Your IdP verifies identity and issues tokens. A service provider (SP) consumes those tokens and grants access to a specific resource. Your ERP system, your SASE platform, your project management tool: these are all service providers that trust assertions from your IdP.
| Identity provider (IdP) | Service provider (SP) | |
|---|---|---|
| Primary role | Authenticates users, issues tokens | Grants access based on trusted tokens |
| Data ownership | User directory, credentials, group memberships | Application resources and data |
| Policy focus | Authentication policy (MFA, conditional access) | Authorisation policy (roles, permissions) |
| Examples | Microsoft Entra ID, Okta, Google Workspace | Salesforce, Jimber SASE, ServiceNow |
How SSO connects your IdP to every application
Single sign-on (SSO) allows a user to authenticate once with the IdP and then access multiple applications without re-entering credentials. This is not just a convenience feature. It reduces password fatigue, cuts the risk of credential reuse across services, and gives IT a single place to enforce authentication policy.
When a user opens a protected application, the SP redirects them to the IdP. The IdP authenticates the user (checking MFA, device posture, conditional access rules), then issues a token back to the SP. The SP validates the token and grants access. If the user moves to a second application, the IdP recognises the existing session and issues a new token without prompting for credentials again.
For IT managers, the operational benefit is significant. One place to enforce MFA. One place to disable a compromised account. One place to review authentication logs. With SSO in place, offboarding a departing employee means disabling one IdP account rather than hunting through dozens of individual application logins.
SAML vs OIDC: which protocol fits your environment
Two protocols dominate identity federation in enterprise environments. Choosing between them depends on your application landscape and integration requirements.
SAML 2.0
Security Assertion Markup Language (SAML) is an XML-based standard designed for web browser SSO. It has deep support across enterprise applications and remains the default choice for on-premises and legacy web apps. A typical SAML flow works like this: the user requests a protected resource, the SP generates an authentication request and redirects the browser to the IdP, the IdP authenticates the user and returns a digitally signed XML assertion, and the SP validates the signature and grants access.
SAML is mature and widely supported, but it is verbose. The XML payloads are large, and mobile and single-page applications often handle them awkwardly.
OpenID Connect (OIDC)
OIDC is a modern authentication layer built on top of OAuth 2.0. It uses lightweight JSON Web Tokens (JWT) instead of XML assertions. OIDC is the better fit for cloud-native applications, mobile apps, and APIs. It supports the same identity federation as SAML but with less overhead and better developer tooling.
When to use which
| Criterion | SAML 2.0 | OpenID Connect (OIDC) |
|---|---|---|
| Best fit | Enterprise web apps, legacy systems | Cloud-native apps, mobile, APIs |
| Token format | XML assertion | JSON Web Token (JWT) |
| Complexity | Higher (XML parsing, certificate management) | Lower (JSON, standard HTTP flows) |
| Mobile support | Limited | Native |
| Adoption trend | Stable, widely deployed | Growing, preferred for new integrations |
Most mid-market environments run both. Your legacy ERP system probably uses SAML. Your cloud-native SaaS tools likely support OIDC. A capable IdP handles both protocols from the same directory, so you do not need to choose one exclusively.
How SCIM keeps your directory and applications in sync
Configuring SSO gets users authenticated. But what about provisioning? When a new employee joins, their account needs to appear in downstream applications. When someone leaves, their access needs to disappear. Manually managing this across a dozen applications creates delays and security gaps.
System for Cross-domain Identity Management (SCIM) solves this. SCIM is a standard protocol that automatically synchronises user accounts, group memberships, and attributes between your IdP and connected applications. When HR creates a user in the directory, SCIM pushes that account to every integrated application. When the account is disabled, SCIM removes access everywhere.
For NIS2 compliance, this matters. The directive expects organisations to demonstrate that access is appropriate and revoked promptly when no longer needed. Manual provisioning with spreadsheets and tickets does not meet that bar. SCIM-based automation provides the audit trail regulators expect.
Why your identity provider is the trust anchor for Zero Trust
Zero Trust flips the traditional security model. Instead of trusting anyone inside the network perimeter, every access request must be verified. Your IdP is the foundation of that verification.
In a Zero Trust Network Access architecture, the ZTNA layer intercepts every connection attempt. Before granting access to a specific application, it checks the user’s identity (provided by your IdP via SAML or OIDC), the device’s security posture (OS version, disk encryption, endpoint protection status), and the access policy for that particular application and role.
This is fundamentally different from VPN-based access. A VPN authenticates once, then grants broad network access. ZTNA authenticates per application and re-evaluates continuously. The IdP makes this possible by providing rich identity context, not just a username, but group memberships, authentication strength, and session metadata that the ZTNA layer uses for every access decision.
What IdP-driven ZTNA looks like in practice
Consider a finance team member working from home. They open their browser and navigate to the invoicing application. The ZTNA layer redirects to the IdP for authentication. The IdP checks their credentials, verifies MFA, and evaluates conditional access rules (is this a managed device? is disk encryption enabled?). If everything passes, the IdP issues a token with the user’s group memberships. The ZTNA layer reads those groups, confirms the user is authorised for the invoicing app, and grants access to that specific application. Nothing else on the network is visible or reachable.
If the same user tries to reach the HR database, the ZTNA layer checks again. The finance group has no access to HR resources, so the request is denied. No lateral movement. No broad network exposure.
Practical integration guide: connecting your IdP to a ZTNA platform
This section walks through the steps to integrate an IdP with a ZTNA platform. The specifics vary by vendor, but the pattern is consistent across Microsoft Entra ID, Okta, and Google Workspace.
Step 1: Exchange metadata
Download the IdP’s SAML metadata XML file (or OIDC discovery URL). This contains the IdP’s SSO endpoint, entity ID, and public signing certificate. Upload it to your ZTNA platform’s administration console. In return, configure the ZTNA platform’s entity ID and Assertion Consumer Service (ACS) URL in your IdP’s application catalogue.
Step 2: Map attributes
Configure attribute mapping between the IdP and the ZTNA platform. At minimum, map email address, display name, and group memberships. Group memberships are the most important attribute because they drive access policies. Map your directory groups (Finance, Engineering, IT Admins) to application-level policies in the ZTNA console.
Step 3: Enable device posture checks
Configure your ZTNA platform to evaluate device health signals alongside identity. Set baseline requirements: managed device status, disk encryption, OS version currency, and active endpoint protection. For personal devices, apply stricter access scopes or limit access to browser-based applications only.
Step 4: Configure SCIM provisioning
For environments with more than 50 users, enable SCIM to automate account lifecycle management. This ensures that user additions, role changes, and departures in your IdP are reflected immediately across all connected applications.
Step 5: Manage certificate rotation
SAML trust relationships depend on X.509 certificates for signing assertions. These certificates expire. Set calendar reminders to rotate signing certificates before expiry. A missed rotation breaks authentication for every user, which is one of the most common causes of SSO outages.
Step 6: Harden the integration
Three hardening steps that prevent token-based attacks. Enable signed authentication requests so your IdP only processes requests from legitimate service providers. Configure audience restriction to ensure tokens are valid only for your specific ZTNA tenant. For sensitive environments (healthcare, finance), enable encrypted assertions so the browser never processes raw identity data.
Common mistakes that break IdP integrations
Mid-market teams often hit the same problems during IdP rollouts. Avoiding these saves weeks of troubleshooting.
Flat group structures. Using broad groups like “All Employees” defeats the purpose of least-privilege access. Create task-level groups that map to specific applications. “AP Invoice Approval” is more useful than “Finance Department” when writing ZTNA policies.
Forgotten service accounts. Machine-to-machine integrations often bypass the IdP entirely, using static API keys instead of proper token-based authentication. Audit these accounts and migrate them to short-lived, scoped tokens where possible.
No conditional access rules. Authenticating identity without checking device posture leaves a significant gap. A compromised personal laptop with valid credentials should not have the same access as a managed, encrypted company device.
Manual provisioning. If user onboarding and offboarding still involves manual steps in each application, access reviews will always lag behind reality. Automate with SCIM.
Ignoring certificate expiry. SAML signing certificates typically expire after one to three years. When they do, SSO breaks instantly for all users. Track expiry dates and rotate proactively.
How IdP integration fits within a SASE architecture
A standalone ZTNA layer solves application access. But most organisations also need web security, site-to-site connectivity, and a way to handle devices that cannot run agents. This is where a unified SASE platform connects the pieces.
In an integrated SASE architecture, your IdP feeds identity context to multiple enforcement points simultaneously. The ZTNA component uses it for per-application access. The Secure Web Gateway uses it to apply user-specific web filtering policies. The Firewall-as-a-Service component uses it for identity-aware traffic rules. SD-WAN ensures the traffic reaches the right destination with consistent performance.
For devices that cannot run an agent, such as printers, IoT sensors, and industrial equipment, NIAC hardware provides inline isolation. These devices sit behind a controller that restricts their communication to explicitly permitted flows, bringing agentless assets under Zero Trust controls without requiring identity-based authentication on the device itself.
The operational advantage is a single console for all of these policies. One place to define who reaches what, under which conditions, from which devices. For small IT teams, this consolidation is the difference between manageable and overwhelming.
European compliance context: IdP and NIS2 alignment
NIS2 requires demonstrable access governance, least-privilege enforcement, and incident containment capabilities. Your IdP integration directly supports several of these requirements.
Access control evidence. IdP-based policies with ZTNA enforcement provide a clear record of who accessed which application, when, from which device, and at what authentication level. This is the evidence auditors expect.
Proportionate access. GDPR requires that access to personal data is appropriate and limited. IdP-driven policies with role-based groups ensure that only authorised personnel can reach sensitive data.
Incident containment. When a breach occurs, disabling a single IdP account immediately revokes access across all connected applications. Combined with ZTNA’s per-application access model, the blast radius of any compromised identity is limited to the specific resources that identity was authorised to reach.
Accountability. Centralised authentication logs from the IdP, combined with access logs from the ZTNA layer, create the unified audit trail that NIS2 demands. SCIM provisioning records add evidence that access lifecycle management is automated and timely.
How Jimber makes IdP integration workable
Jimber’s SASE platform integrates with major identity providers through SAML 2.0 and OIDC. The platform uses your existing IdP as the trust anchor for all access decisions, combining identity verification with device posture checks in a single policy engine.
In practice, this means your directory groups drive access to specific applications through ZTNA, web filtering policies through the Secure Web Gateway, and network segmentation across sites through SD-WAN. Agentless devices are isolated behind NIAC hardware with traffic restricted to explicitly permitted flows. All of this is managed from one cloud console with transparent pricing and multi-tenant support for MSPs.
The integration follows the steps outlined above: metadata exchange, attribute mapping, posture configuration, and SCIM provisioning. Most mid-market teams complete the initial setup in days, not weeks, because the platform is designed for fast onboarding without complex migration projects.
FAQ
What identity providers work with ZTNA platforms?
Most ZTNA platforms support any IdP that implements SAML 2.0 or OIDC. Microsoft Entra ID, Okta, Google Workspace, and Ping Identity are the most common in European mid-market environments.
Do I need to replace my current IdP to adopt Zero Trust?
No. ZTNA platforms connect to your existing IdP. The goal is to use your current directory and authentication infrastructure as the trust anchor for more granular, per-application access policies.
How does SAML differ from OIDC in practice?
SAML uses XML-based assertions and fits legacy enterprise web applications well. OIDC uses lightweight JSON tokens and is better suited for cloud-native and mobile applications. Most organisations run both protocols from the same IdP.
What role does SCIM play in Zero Trust access?
SCIM automates user provisioning and deprovisioning across applications. It ensures that access changes in your IdP are reflected immediately, which is necessary for NIS2 compliance and reduces the window of risk from stale accounts.
Can small IT teams manage IdP integration without a dedicated IAM specialist?
Yes. Modern ZTNA platforms simplify the integration to metadata exchange, attribute mapping, and policy configuration. A team familiar with their IdP’s administration console can complete the setup. Platforms with a single management console reduce ongoing overhead significantly.
How does device posture work alongside IdP authentication?
The IdP verifies the user’s identity. The ZTNA platform evaluates the device’s security state. Access is granted only when both checks pass. This prevents a valid credential on a compromised device from reaching sensitive applications.
Ready to turn your identity provider into the trust anchor for every access decision? Book a demo and see how IdP integration works in Jimber’s SASE console.
