Okta Directory Integration - An Architecture Overview
For most companies, Active Directory (AD) or LDAP plays the central role in coordinating identity and access management policies. Directory integration typically serves as a "source of truth" for user identities, and it provides access control to on-premises resources such as networks, file servers, and web applications. A byproduct of the transition to cloud applications is the proliferation of separate user stores; each cloud application typically is rolled out independently and therefore has its own unique database of user credentials.
Okta's cloud-based identity and access management service solves these problems with a single integration point that provides a highly available solution for all cloud and web-based applications Active Directory integrations.
Read this whitepaper to learn how Okta eliminates the pitfalls that come with trying to build and manage multiple on-premises active directory integrations yourself.
User Directories and the Cloud: An Overview
For most companies, Microsoft Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) directories such as SunOne or Oracle Internet Directory play the central role in coordinating identity and access management policies. AD/ LDAP typically serves as a “source of truth” for user identities and provides access control to on-premises resources such as networks, file servers, and web applications (see Figure 1). When on-premises applications are integrated to Active Directory or LDAP, users get the best possible experience: they log in to their domain once and are granted access to the appropriate resources. Administrators benefit too—they maintain clear control over who has access to what. This model is ubiquitous because it works well with LAN-based architectures (where applications are served from hardware inside the firewall). But as we’ll show, this approach begins to break down as enterprises shift to cloud-based applications, and a new solution is needed.
Figure 1: AD or LDAP for on-premises application user identities
A byproduct of the transition to cloud applications is the proliferation of separate user stores; each cloud application typically is rolled out independently and therefore has its own unique database of user credentials (see Figure 2). This is a minor nuisance with only one or two applications, but as companies adopt more and more cloud applications, administrators are faced with an unmanageable number of different user directories. And this problem is only getting bigger. Users’ passwords proliferate with each new application, and administrators quickly lose control over who has access to what. Worse still, when an employee leaves, most companies cannot easily and accurately identify which accounts to deactivate, nor do they have any auditing capabilities to ensure the necessary deprovisioning occurs in a timely manner.
Figure 2: Adoption of cloud applications leads to proliferation of user stores
One solution to the problem of independent user store proliferation is to attempt to integrate all cloud applications to a single, shared identity store (see Figure 3). Active Directory or LDAP user stores are by far the most convenient options for this, as they can provide identity management for both on-premises and cloud-based applications. Some cloud application vendors provide APIs or toolkits that allow enterprises to try to connect the application’s standalone identity stores to AD or LDAP. However, integration via APIs requires custom development, and each of the toolkits is different and can often require significant investment in setup, equipment (hardware to run the connector software),and maintenance as the applications change over time. As the number of cloud applications increases, this model of per-app AD or LDAP integrations becomes prohibitively expensive. There is always the next new application that the business needs to run.
Figure 3: Integrating with multiple cloud applications is costly and difficult to maintain
Okta’s cloud-based identity and access management service solves these problems with a single integration point that provides a highly available solution for all cloud and web-based application AD and LDAP integrations.
Okta eliminates the pitfalls that come with trying to build and manage multiple on-premises directory integrations yourself:
Pitfall of DIY AD/LDAP integrations |
Okta's Approach |
Do you have the correct skillset to develop these integrations? |
With Okta, integrations do not require programming or development experience and can be accomplished in minutes through our easy-to-use interface |
How will you upgrade and maintain integrations? |
Okta works with ISVs and monitors changes and upgrades to existing APIs to take advantage of the latest functionality; we release updates weekly to reflect changes. |
How do you monitor the health of the integration? |
Okta continuously monitors and tests existing integrations to ensure that the integration functions as expected after upgrades and releases. |
Which protocol will you use to connect to each cloud application? |
Okta eliminates the need to know SAML, OAuth, SCIM, and numerous other integration protocols, because Okta manages these integrations for you. |
What happens when the server running your home-grown, toolkit-based integration fails? |
Okta automatically enables failover recovery with a redundant-agent architecture. |
How will you integrate your cloud app with a multiple domain AD or LDAP configuration? |
Okta has built-in support for multiple AD and/or LDAP domain environments. |
What firewall changes are needed for each cloud app-to-AD/LDAP integration?
|
With Okta, there are no firewall changes needed to support AD or LDAP integration.
|
Once in place, Okta provides an infrastructure that allows companies to freely pursue new cloud ap