Directory Services and Identity Providers

Your directory service is the single source of truth for every digital identity in your organisation. It is the database that answers the question “who exists, and what attributes do they have?” The Identity Provider (IdP) is the service that uses that directory to authenticate users and issue tokens to applications. In some products these are the same system; in others they are separate. Understanding the distinction — and knowing which products fill which role — is essential for making sound architectural and procurement decisions.

What a Directory Service Does

A directory service stores and organises identity information in a structured, queryable format. At minimum, this includes usernames, group memberships, and authentication credentials. In practice, modern directories also store attributes like department, job title, manager, location, phone number, licence assignments, and device registrations.

The directory is not just an address book. It is the authoritative data source that every other system in your IAM ecosystem depends on. When an application needs to know whether a user exists, what groups they belong to, or whether their account is active — it asks the directory.

The Major Directory and IdP Products

Five products dominate the enterprise identity landscape. Each has distinct strengths, ideal use cases, and licensing models.

Microsoft Active Directory Domain Services (AD DS)

AD DS is the most widely deployed on-premises directory in the world. It runs on Windows Server and provides LDAP-based directory services, Kerberos authentication, and Group Policy for device management. Nearly every organisation that has used Windows servers in the past two decades has Active Directory. Its strengths are maturity, deep Windows integration, and a massive ecosystem of compatible applications. Its weaknesses are that it requires on-premises servers, does not natively support modern authentication protocols (SAML, OIDC), and managing multi-site AD topologies is operationally complex.

Microsoft Entra ID (formerly Azure Active Directory)

Entra ID is Microsoft’s cloud identity platform and is fundamentally different from on-premises AD despite the legacy naming. It natively supports SAML, OIDC, and OAuth 2.0. It provides conditional access policies, identity protection (risk-based authentication), privileged identity management, and SCIM provisioning. Every Microsoft 365 tenant includes Entra ID at the Free tier; P1 and P2 licences unlock advanced security features. Entra ID is the natural choice for Microsoft-centric organisations and is increasingly the strategic IdP even for organisations that also run on-premises AD.

Okta

Okta is the leading independent cloud identity platform. Its core strength is vendor neutrality — it integrates deeply with thousands of SaaS applications regardless of the underlying infrastructure. Okta’s application integration network (OIN) is the largest catalogue of pre-built SSO and SCIM connectors. It excels in multi-cloud environments and organisations that want to avoid vendor lock-in to a single cloud ecosystem. Okta also offers Okta Workforce Identity Cloud for employees and Okta Customer Identity Cloud (formerly Auth0) for customer-facing applications. Licensing is per-user, per-month, with tiered feature sets.

Ping Identity

Ping Identity targets large enterprises with complex, heterogeneous environments. It is particularly strong in scenarios requiring fine-grained access management, API security, and hybrid deployments where some components must remain on-premises. Ping offers both cloud (PingOne) and self-hosted (PingFederate, PingAccess) deployment options. Financial services, healthcare, and government organisations often choose Ping for its flexibility and advanced federation capabilities. The trade-off is greater implementation complexity compared to Okta or Entra ID.

Google Cloud Identity

Google Cloud Identity provides directory and IdP services tightly integrated with Google Workspace and Google Cloud Platform. It supports SAML and OIDC for SSO to third-party applications, and provides device management capabilities. It is the natural choice for Google-centric organisations but has a smaller third-party application integration ecosystem compared to Entra ID or Okta. Google Cloud Identity Free provides basic directory and SSO; Premium adds device management, security investigation tools, and advanced reporting.

IdP Selection Criteria

Choosing an Identity Provider is a multi-year strategic decision. The following criteria should guide your evaluation:

• Ecosystem alignment: If you are a Microsoft 365 organisation, Entra ID provides the deepest native integration. If you are Google Workspace, Google Cloud Identity is the natural choice. If you are multi-vendor or want independence, Okta is the strongest option.
• Application integration catalogue: How many of your current and planned SaaS applications have pre-built connectors? Building custom integrations is expensive and fragile.
• Security feature depth: Compare conditional access, risk-based authentication, identity governance, and privileged access management capabilities across vendors. Many advanced features require premium licence tiers.
• Total cost of ownership: Compare not just licence costs but implementation effort, ongoing administration, training, and the cost of any additional modules or connectors required.
• Hybrid support: If you have on-premises Active Directory, evaluate each vendor’s AD integration agent and synchronisation capabilities.
• Compliance and data residency: Where is identity data stored and processed? Does the vendor offer data residency options that meet your regulatory requirements?
• Vendor stability and roadmap: IAM is a long-term commitment. Evaluate the vendor’s financial stability, innovation pace, and strategic direction.

AWS IAM: A Special Case

AWS IAM deserves mention because many organisations use Amazon Web Services, but it is important to understand that AWS IAM is not a workforce identity provider. It governs access to AWS resources — who can create EC2 instances, read S3 buckets, or modify Lambda functions. It does not manage employee logins to your email, CRM, or HR system. For workforce identity, AWS recommends using AWS IAM Identity Center (formerly AWS SSO), which federates with your chosen external IdP (Entra ID, Okta, etc.) to manage human access to AWS accounts.

Why This Matters

Your choice of directory and Identity Provider affects every downstream IAM capability — SSO, MFA, provisioning, access governance, and audit. Switching IdPs after deployment is a major migration project that can take twelve to eighteen months and cost six figures or more. The time to evaluate thoroughly is before you commit, not after. Furthermore, many security features that executives assume are included — conditional access, identity protection, automated provisioning — often require premium licence tiers. Understanding what you’re paying for versus what you’re getting is critical for avoiding both security gaps and budget surprises.

What to Do Now

• Confirm which directory service and Identity Provider your organisation currently uses and at what licence tier.
• Identify whether you are using features that require a premium licence — or whether premium features are available but not enabled.
• Document your IdP’s current uptime SLA and compare it with your business’s tolerance for authentication outages.
• If you are evaluating a new IdP, create a weighted scoring matrix using the criteria above, customised to your organisation’s priorities.
• Map your top 20 applications and verify which ones have pre-built SSO/SCIM connectors with your IdP.

Evidence to Collect

• Your current IdP product name, version (if on-premises), and licence tier.
• A list of security features available at your licence tier versus features enabled and in active use.
• The number of applications integrated with your IdP via SSO and SCIM.
• IdP uptime and availability records for the past twelve months.
• Documentation of any planned IdP migration or upgrade projects.

Common Mistakes

• Confusing AWS IAM with a workforce Identity Provider. AWS IAM manages access to AWS resources. It does not replace Entra ID, Okta, or any other workforce IdP. Organisations that try to use AWS IAM as their primary identity system create fragmented, ungovernable environments.
• Buying premium licences but not enabling premium features. Many organisations pay for Entra ID P2 or Okta Advanced but never configure conditional access, risk-based policies, or identity governance features. Audit your licence utilisation regularly.
• Selecting an IdP based on brand loyalty rather than fit. “We’re a Microsoft shop” is not sufficient justification if your application portfolio is multi-vendor and your workforce is primarily remote. Evaluate objectively using weighted criteria.
• Underestimating migration complexity. Changing your IdP affects every integrated application, every conditional access policy, every provisioning workflow, and every user’s login experience. Plan for twelve to eighteen months and budget accordingly.

---

Knowledge Check

---