IdP AS A Service (IdPaaS)

Andi Lamprecht ·2026-05-11· 3 min read· Accepted

IT Identity Provider As A Service (IdPaaS)

Context

IT Operations started the democratization of Okta as a Service. In going down this path, it was found that DroneUp uses more than just Okta as an IdP and the need for IdPaaS arose. AzureAD is required for Intune and managing Windows devices. Lumos provides access and authorization requests. FrontEgg is a new addition as an IdP.
Additionally while working with Okta in Terraform Cloud, it was discovered that splitting up the state files across multiple workspaces increases the speed of deployments.

By democratizing the IdP we will be able to increase productivty of develpers by eliminating administrative overhead, while still maintaining a secure envrionment. This will streamline access management, eliminate bottlenecks, and leverage modern IaC practices.

Decision Driver

After working in the Okta repo, the scope was quickly increased to include Lumos and AzureAD for UEM purposes. With this expansion, the concern of State bloat quickly came up. This will allow for a more streamlined approach and limit the state file bloat.

Decision

IT Operations will create a new repo with multiple Terraform Cloud Workspaces.
This repo will house all of the Okta, Azure AD, Lumos configurations and FrontEgg IdP tenant-level configurations.

The following folder and workspace structure will be used.
Each (state) listed is a new workspace.
Workspace names will be in the format it-idpaas-<foldername>.

|-- it-idp
   |-- dev  (state)
   |-- prod
        |--adminstrative  (state)
        |--sso
        |   |--application
        |   |   |--sso_apps     (state)
        |   |   |--lumos_apps   (state)
        |   |--front_egg
        |   |   |--tenant-a     (state)
        |   |   |--tenant-b     (state)
        |   |--group
        |        |--sso_app_assignments      (state)
        |        |--sso_app_user_groups      (state)
        |        |--iam_groups               (state)
        |--uem
            |--department_groups        (state)
            |--uem_assignment_groups    (state)
            |--azuread_groups
                |--parent_nesting_groups (state)
                |--build_groups          (state)

Note: “sso_” refers to the chosen IdP that the company is utilizing. At the time of writing, it is Okta.

Consequences

1. Single Repo that holds all of the IdP configurations but with separate Terraform workspaces.

   • Good, simpler management of all IdP configurations.
   • Good, split workspaces and state files for faster plan executions.
   • Bad, complex folder structure may be difficult to understand for new users.

Alternatives Considered

1. Single Repo with all IdP configurations with single Terraform workspace for production.

   • Good, simpler management of all IdP configurations.
   • Bad, difficult to read due to everything being a flat file structure.
   • Bad, longer plan times as everything is in a single state file.
   • Bad, only a single plan can occur at a time.

Cited by queries

• DroneUp roles and permissions: as-is across Uncrew, Hubops, UTM, Boundary Creator, Frontegg, Okta, and Lumos — 2026-05-01