Apache Airflow SSO and identity integration guide

Apache Airflow SSO starts with choosing an auth manager

In Airflow 3, single sign-on is set up through the auth manager, and only one auth manager is active at a time, selected with the auth_manager option. That one choice shapes how staff sign in, how group membership becomes Airflow permissions and how API clients authenticate, so settle it before configuring anything else. Airflow 3 defaults to the Simple auth manager, which is not the corporate sign-in mechanism this page covers, so confirm its user and role model in the auth manager documentation before relying on it for anything beyond initial testing. The FAB auth manager comes from the FAB provider package, so it is installed and versioned separately from core Airflow. Compare the options against your identity provider and your access model before you choose.

The webserver that earlier Airflow versions used for the browser interface has been replaced by an API server, started with airflow api-server. Login and API access both route through that component, so it is the point where your identity decisions take effect. Plan the two paths separately. People sign in through a browser and expect their group membership to decide what they can see and trigger. Automation, such as CI jobs, monitoring tools and external systems, calls the REST API and needs its own identity, usually a service account with narrow permissions. Ask the team that will run Airflow which systems will call the API, since that list drives the design more than the login screen does.

Several parts of this look simpler than they are. Role mapping comes first: identity provider groups must map to Airflow roles, and a group that is missing or misnamed either locks people out or grants more access than intended. Service accounts come second, because automation needs identities that survive staff changes and have a named owner. Token handling is third. Decide how API tokens are issued, how long they live, where clients store them and how a compromised token is revoked, and confirm each behavior for the version you install. Configuration is the fourth challenge. OAuth and LDAP options, their parameter names and their defaults differ by provider and by Airflow and provider package version, so the exact settings must be confirmed against the provider documentation for the installed version before anything goes to production.

Before any configuration work, write down four things: the identity provider and the protocol you will use for Airflow sign-in, the list of groups that should map to each role, the non-human identities that call the API along with their owners, and the environment where sign-in will be tested first. Then confirm with the provider documentation that your chosen auth manager supports each of those needs in the Airflow version you plan to run. If a need is not covered, treat it as a design decision to settle before the build starts, and record the decision so the team that runs Airflow later can see why it was made.

Components involved in Airflow identity integration

An Airflow SSO build spans the API server, the auth manager setting, the identity provider, the claims it returns, the roles inside Airflow and the REST API that automation uses. Each part needs an owner and a decision before configuration starts, because a change in one usually affects the others.

API server process

In Airflow 3 the web interface and REST API are served by the API server, started with airflow api-server. Authentication for the user interface and API calls is enforced here, so login redirects, session handling and callback URLs all depend on how this process is deployed. Confirm the exposed base URL, the TLS termination point and how the process is replicated, since the identity provider must redirect users back to exactly that address.

The auth_manager option

The auth_manager option selects the single auth manager that Airflow uses at any one time. Choosing the wrong value or changing it late forces a reconfiguration of login, roles and API access together. Confirm the value in every environment and in every container image or Helm values file, and check that all API server replicas read the same setting.

Simple auth manager default

The Simple auth manager is the default in Airflow 3. It is useful for evaluation and early builds, but it is not an identity integration with your provider. Confirm whether it is still active in your deployment, and plan an explicit switch to the chosen manager so that no environment runs on defaults by accident.

FAB auth manager from the FAB provider

The FAB auth manager is supplied by the FAB provider package, not by Airflow core, so it must be installed at a version compatible with the Airflow release in use. It is the path for OAuth and LDAP login with role mapping. Confirm the provider version pinned in your image, the installed dependencies and whether the provider will be updated alongside Airflow upgrades.

Identity provider endpoints

The identity provider exposes OAuth or OpenID endpoints, or an LDAP directory, that Airflow calls for authentication. Each endpoint has its own certificate chain, client registration or bind account, and availability requirements. Confirm the redirect URIs registered with the provider, the TLS trust store on API server hosts and who owns credential rotation for the client secret or bind account.

Group and claim data

The provider returns user attributes such as groups, roles or claims, and Airflow maps them to its own roles. Mapping depends on the exact claim names and whether groups arrive as names or identifiers. Confirm which claims the provider emits for each group, how nested or large group lists are handled, and what happens to a user who has no mapped group.

Role definitions inside Airflow

Airflow roles define what authenticated users may see and change, such as DAGs, connections and variables. The mapping from provider groups to these roles is the access control decision of the whole build. Confirm the role list against your least-privilege design, who may edit the mapping, and how a removed group membership revokes access in the metadata database.

REST API for automation

Automation such as CI pipelines, monitoring jobs and deployment scripts calls the REST API, which must keep working when interactive login is changed. Service accounts or tokens may need a different path from human SSO. Confirm how each automated client authenticates, who owns those credentials and how they are rotated and revoked without disrupting user login.

Which auth manager and identity path to choose

This table compares the five realistic ways to authenticate users to Airflow 3, from the built-in Simple auth manager to a gateway in front of the API server. Read each row for when the option fits, what it costs to run, and what to confirm with the identity team before committing, because only one auth manager can be active at a time.

Option	When it fits	Operational cost	Confirm before choosing
Simple auth manager	Small, trusted group of operators where shared access is acceptable and no per-user audit trail is required	Lowest setup effort and no identity dependency; limited role separation, so any change to access policy still needs a configuration change and restart	Whether the group is small enough and trusted enough that per-user accountability and offboarding are not compliance requirements
FAB auth manager with OAuth (OIDC)	Organization already runs an OIDC-capable identity provider and wants SSO with group-based roles for users of the Airflow UI and API	FAB comes from the FAB provider package, so provider version pinning and upgrade testing are ongoing work; OAuth callback and token settings must be maintained; the login path depends on the IdP being reachable	Supported OIDC features and claim names, how groups are published in tokens, client registration ownership, and the IdP's session and token lifetimes
FAB auth manager with LDAP	Users and groups live in an Active Directory or LDAP directory and the organization does not want a separate SSO service for Airflow	Directory bind account and search filters need maintenance; group-to-role mapping is configured in Airflow; directory outages block logins; provider upgrades need regression testing against the directory	Bind account policy, TLS requirements for the directory connection, group distinguished names to map, and who approves changes to directory groups
Custom auth manager built in house	Requirements the FAB provider cannot meet, such as a proprietary identity system or unusual authorization model	Highest ongoing cost: the team owns the code, tests it against every Airflow upgrade, and handles security fixes; knowledge can leave with the original authors	Whether the team can staff ongoing maintenance, which Airflow 3 interfaces the custom code depends on, and who signs off on security review
Authenticating reverse proxy or gateway	Central access gateway already enforces SSO for internal applications and the organization wants one login policy in front of Airflow	Proxy configuration, header trust and session handling become part of the Airflow security boundary; API clients may need a separate token path; gateway outages affect all access	How identity headers are signed or validated, whether API clients can authenticate through the gateway, and who owns gateway change control

How to build Airflow SSO step by step

This sequence moves an Airflow 3 deployment from the default Simple auth manager to sign-in through your identity provider, with access driven by group membership. Each step closes with a check you can run, so a fault surfaces before the pilot group or wider users are onboarded.

Confirm the Airflow 3 version and prerequisites
The platform team pins the Airflow 3 release it will run, using the version life cycle table to confirm the current patch line, and checks the Python, metadata database and Kubernetes versions listed for that release. Airflow 3 was first released on April 22, 2025, and the current patch is 3.3.2, so confirm the patch level again on the day the build starts. Use PostgreSQL or MySQL for the metadata database, since SQLite is for testing only and MariaDB is not supported. Done when the target versions are recorded in the change ticket and a test environment starts the API server and the DAG processor as separate components.
Choose the auth manager
The security lead and the Airflow owner decide between the Simple auth manager, which is the default in Airflow 3, and the FAB auth manager from the FAB provider package, which supports identity-provider sign-in through OAuth or LDAP. Only one auth manager can be active at a time, so this choice shapes the rest of the build. Record the reason, the identity protocol each user population needs, and who approves later changes. Done when the decision record names one auth manager, lists the identity sources it will trust, and identifies the owner of group mappings.
Install the FAB provider package
If the FAB auth manager was chosen, the platform engineer installs the FAB provider package into the image or Python environment that runs the API server, pinned to a version compatible with the Airflow 3 release confirmed in the first step. Build the image from source control so the package version is recorded and repeatable across every API server replica. Install it on all API server instances, not only one node. If the Simple auth manager was kept, skip this step and confirm the API server still starts. Done when the API server starts with the FAB auth manager available and the provider version appears in the image manifest or environment listing.
Register Airflow with the identity provider
The identity team registers Airflow as an OAuth or OpenID Connect client in the identity provider, or sets up the LDAP bind details if directory authentication is used. Set the callback address to the public address of the API server, using the callback path documented for the auth manager, and request only the scopes the role model needs. Store the client identifier and secret in the team's secrets store, and ask the identity provider administrator which group claims appear in the token. Done when a test sign-in returns to Airflow without error and the groups claim for a test user contains the expected values.
Set auth_manager and provider settings securely
The platform engineer sets the auth_manager option to the chosen auth manager and adds the provider settings from the auth manager documentation for the Airflow 3 release in use. Put the client secret and any signing or encryption keys in environment variables or the secrets backend, and confirm each setting name against the documentation before writing it down. Keep credentials out of plain config files in source control. Done when the API server starts with the setting applied, the client secret does not appear in the rendered configuration or logs, and a login attempt redirects to the identity provider.
Define roles and map groups
The security lead and application owners write the role model: which identity-provider groups receive which roles from the set the chosen auth manager exposes, and which DAGs or resources each role can reach. Map each group to one role, and limit broad administrative roles to a small, named group. Keep the mapping in version-controlled configuration with a named owner for each change, and confirm role names against the auth manager documentation. Done when a token for a test user from each mapped group returns the expected role, and a user in an unmapped group is denied access.
Lock down API server and service accounts
The platform team restricts the API server to the networks and load balancers that need it, and separates human sign-in from the service accounts that DAGs or automation use. Service accounts should authenticate through a method that does not depend on a person's session, with credentials held in the secrets backend and scoped to the roles they need. Scan the API server from outside the allowed network ranges to confirm which endpoints are reachable. Done when an unauthenticated request to a protected endpoint is refused and a service account can call only the endpoints its role allows.
Test sign-in with a pilot group
A small pilot group from one team signs in through the identity provider, runs representative DAGs, and attempts actions outside its role, while the audit logs are reviewed for those sign-ins and denials. Fix any mapping error in the version-controlled configuration and retest before wider rollout. Record each test case with its expected result so the same checks can be repeated after upgrades. Done when the pilot group completes its agreed scenarios, users from unmapped groups are denied, and the security lead and Airflow owner sign off the test record.

How to map identity provider groups to Airflow roles

The mapping is the most consequential access decision in an Airflow SSO rollout, so make it deliberately before go-live. When a user signs in, the identity provider sends groups or claims, and Airflow must translate them into roles and DAG-level permissions. With Airflow 3 the auth manager is selected through the auth_manager option, and only one can be active at a time. If you use the FAB auth manager from the FAB provider, the mapping logic lives in that provider's configuration, so the group-to-role table is the artifact to design first. Before writing anything, confirm the claim name, the group format (names or identifiers) and the role names that your installed FAB provider version expects, because these differ between releases and between identity providers.

Keep the mapping small enough that one person can read it in a few minutes. A practical pattern is one identity provider group per Airflow role or per team-scoped permission set, with no group granting rights that no one can explain. Users who belong to several groups will receive the combined permissions of all of them, so decide in advance which combinations are acceptable and test them with a sample account in each. Avoid mapping a broad group such as an all-staff or general engineering group to Admin. Reserve the Admin role for a small group owned by the platform team, and confirm whether your provider version grants Admin only through an explicit mapping or also through a default role setting.

Plan for group changes and offboarding as ordinary operations, not exceptions. Confirm how your FAB provider version refreshes roles: whether roles are recalculated at each login, or whether they persist on the local user record until an administrator changes them. Either behavior affects how quickly a removed group membership takes effect. Test the offboarding path end to end: disable or remove a test user in the identity provider, then confirm that the web login fails, that existing sessions expire as you expect, and that any API credentials the user created are revoked or still need a manual step. Write the result down, because the identity team and Airflow owners will each assume the other handles this.

Document the mapping as one shared record that both the identity team and the Airflow owners review. For each row, record the identity provider group name and identifier, the Airflow role, the DAG or team scope it applies to, the business owner, and the date of the last review. Store the document in version control so every change has an author and a reason, and require approval from both teams for any change. Review the table on a fixed schedule and again before each Airflow upgrade, since role definitions and permission checks can change between releases. Ask your Airflow provider release notes and the identity provider documentation to confirm each claim and role name before you sign off.

What drives effort and cost in an Airflow SSO project

This table lists the factors that move effort and cost in an Airflow 3 identity project and the steps that keep each one contained. Read each row as a lever: the driver explains why it changes the work, and the control shows what to settle before the build starts. The main takeaway is that group design and environment reuse usually matter more to the final effort than the choice of protocol.

Driver	Why it changes effort or cost	How to keep it down
Number of identity providers	Each federated or separate provider needs its own callback configuration, claim mapping and test cases, and multiplies verification work.	Confirm which single provider is the source of truth before the build and treat any second provider as a separate scoped item.
OAuth versus LDAP	OAuth or OpenID Connect through the FAB auth manager usually needs client registration and claim checks, while LDAP needs directory bind accounts, search filters and certificate handling.	Choose the protocol your identity team already operates and document the claims or attributes Airflow will read.
Count and complexity of groups	Every directory group that maps to an Airflow role adds a mapping rule, a test case and an owner to approve access.	Standardize group names and membership rules before the build, and map only groups that grant a real Airflow permission.
Roles and custom permissions	Custom roles, or changes to default role permissions, need design decisions, review and regression tests after each upgrade.	Limit roles to the defaults where possible and record every custom permission with the reason it is needed.
Automation service accounts and API clients	Each DAG deployment pipeline, monitoring tool or script that calls the REST API needs its own identity, credential rotation and permission check.	Inventory every non-human caller in the design phase and give each one the narrowest role and a named owner.
DAG-level access requirements	Restricting who can view or trigger specific DAGs or teams adds per-resource rules that must be designed, tested and explained to auditors.	Decide whether access stops at role level or needs DAG-level rules, and avoid per-DAG exceptions unless a team has a documented need.
Environments (dev, test, production)	Each environment needs its own client registration, redirect addresses, group mappings and test evidence, so the work repeats.	Build one configuration pattern with environment-specific values only, and reuse the same test cases in every environment.
Hosting model (VM, Kubernetes, air-gapped)	Kubernetes deployments handle secrets and configuration through the chart or manifests, air-gapped networks need offline copies of identity metadata and packages, and VM installs need service-level configuration.	Confirm the hosting model in the scope, and check that the identity provider is reachable from the Airflow API server network path.
Compliance evidence and access reviews	Assessors may ask for group membership exports, role assignments, change records and periodic access review results, which takes extra design and recurring effort.	Agree on the evidence list before the build and make sure the identity provider can export group membership on a schedule.

How SSO setup changes by deployment model

On a single host, the API server, scheduler, DAG processor and workers usually run on the same machine, so the auth configuration is read from one Airflow configuration file and one set of environment variables. The redirect URL points directly at the API server's address, and TLS is either terminated by the API server or by a reverse proxy placed in front of it. The identity provider must reach the callback endpoint from users' browsers, and the API server must reach the identity provider for discovery and token exchange.

Config location: set the auth manager and FAB provider options in the Airflow configuration or environment variables on that host, and keep the file readable only by the Airflow service account.
Redirect URL: register the exact public address of the API server, including scheme and port, with the identity provider.
TLS: if a reverse proxy terminates TLS, configure forwarded headers so generated links use https.
Secrets: supply the client secret through an environment variable or a file readable only by the service user, and keep it out of DAG code and version control.
Reachability: allow outbound access from the API server to the identity provider's endpoints. Workers on the same host need no separate route.

Check that the registered redirect URL matches the address the browser shows after sign-in, because a mismatch in one character will block login.

Securing API access and login paths in Airflow

Once Airflow trusts an identity provider, the login path, the API server and the service accounts become the main entry points to check. The cards below cover the identity-specific controls that connect them, from where OAuth and LDAP secrets live to how sessions expire and how logins are audited. General platform hardening is covered on the security hardening page and is not repeated here.

Store OAuth and LDAP secrets in a backend

The OAuth client secret or LDAP bind password should never sit in airflow.cfg, environment files committed to git, or Helm values in plain text. Use a secrets backend that your infrastructure team already operates, and confirm that the API server and scheduler can read the secret while no end user or DAG author can. Check which Airflow configuration keys accept a secret reference in your chosen auth manager and provider version, because this varies and should be confirmed against the release you deploy.

Enforce TLS to the identity provider

Traffic between the API server and the identity provider carries credentials and token exchanges, so it must use TLS with certificate validation enabled. Confirm the certificate authority chain for internal identity providers is trusted by the API server container or host, and that LDAP connections use LDAPS or StartTLS rather than cleartext on port 389. Disabling certificate verification to get a connection working is a finding to fix before go-live, not a workaround to keep.

Set token lifetime and session limits

Decide how long a browser session and any API token remain valid, and how quickly a disabled user loses access. Shorter lifetimes reduce the window for a stolen token, but they increase re-authentication for operators who monitor long-running DAGs. Confirm which session and token timeout settings the auth manager exposes in your release, and test that a user removed in the identity provider is refused on the next request.

Use narrow service accounts for automation

CI pipelines, monitoring tools and deployment jobs should authenticate as dedicated service accounts, not as a person's login. Give each account only the Airflow role needed for its task, such as triggering a named DAG or reading run status, and avoid granting admin. Record which account owns each automation so that revoking one integration does not affect others and so that API calls are attributable.

Rotate client secrets and bind credentials

OAuth client secrets, LDAP bind passwords and service account credentials all need a rotation procedure before go-live. Agree the owner, the frequency your policy requires and the steps to update the secrets backend and restart or reload the API server without downtime. Test one rotation in a non-production environment, and confirm that old credentials stop working after the cutover.

Block anonymous access to the API server

The Airflow 3 API server serves the UI and the REST API, so every endpoint that is not meant for public use must require authentication. Place the API server behind your approved network path, restrict direct exposure from the internet, and verify with unauthenticated requests that protected endpoints return an authentication error. Confirm which endpoints, if any, are intentionally open for health checks and document them.

Audit logins and role changes

Logins, failed logins, token issuance and changes to role assignments should be recorded in a place the platform team cannot silently edit. Confirm which events the auth manager logs by default, where those logs go, and how long your retention policy requires them to be kept. Map each event to a named owner who reviews it, because logs that nobody reads do not support an access review.

Keep the Fernet key separate from SSO secrets

The Fernet key encrypts connection passwords and variables stored in the metadata database, while OAuth client secrets and LDAP bind credentials protect the login path. They are different secrets with different owners and rotation effects, so one should never be used as a stand-in for the other. Rotating the Fernet key requires re-encrypting stored values, whereas rotating an SSO secret requires updating the identity provider, so plan and test them as two separate procedures.

How to verify Airflow SSO and keep it working

Verification of Airflow SSO should start with a written test matrix, because a login that works for one administrator proves very little. Run each case against the same Airflow 3 environment that users will reach, using the auth manager and identity provider settings you intend to ship. The matrix should cover six cases with an expected result for each. A user who belongs to each mapped group should land on the role that group is mapped to, and no more. A user who belongs to no mapped group should be signed in without any Airflow role, or refused, depending on how your FAB auth manager configuration handles that case. An expired or revoked account should be unable to start a new session, and an existing session should end within the lifetime you have configured. A service account token should be accepted only for the API scope it was issued for. An unauthenticated call to the REST API should receive a denial, not data. Finally, a login attempt while the identity provider is unreachable should fail with a clear error and grant no access.

Failures should fail closed. If group claims are missing, malformed or empty, Airflow should deny access or fall back to the least privileged role, never to Admin. If the identity provider cannot be reached, the login path should stop rather than trust a cached assertion it cannot validate. Ask your integrator to show you the exact behavior for each case in your environment, and record it. Where the documentation for your FAB provider version does not clearly state a default, confirm the behavior by test rather than assuming it.

After go-live, the work shifts to operations. Monitor failed logins, denied API calls and changes to the auth configuration, and send them to the team that owns the identity integration. Review group-to-role mappings on a fixed schedule, and remove mappings for groups that no longer have a business owner. Rotate the OAuth client secret and any LDAP bind credential on a schedule your security policy sets, and confirm that the Airflow configuration and any secrets backend are updated together so logins do not break silently.

Re-run the full test matrix after every Airflow upgrade and every FAB provider upgrade, because auth manager behavior and provider packages change independently of your DAGs. Treat a failed case as a release blocker. Keep the upgrade notes for the auth manager with the change record. Document the auth configuration, including the identity provider application, redirect URIs, mapped groups, service accounts, owners for each element, and the steps for a periodic access review. Ask whoever signs off the review to confirm that each account and group still has a current owner.

Questions teams ask before setting up Airflow SSO

Can our own team set up Airflow SSO without outside help?

Yes, if your team already runs Airflow 3 and can administer your identity provider. The core work is choosing an auth manager, registering Airflow as an application with your identity provider, and mapping groups to roles. Teams with an identity engineer and a separate test environment often handle it in-house. The harder parts are design decisions that shape later access: which user claims identify people, how nested groups are read, and how automation accounts and API access are handled. Most in-house setbacks come from testing with a single admin account, skipping a written test plan, or changing production login without a rollback path. Before deciding, check whether your team has a documented access review process and a change window for identity changes. If both exist, in-house work is a sound option.

Is Apache Airflow SSO free to use?

The software is free to use. Apache Airflow is released under the Apache License 2.0 (Apache-2.0), and the project itself offers no paid edition. The cost sits in the work around the software: designing identity access, configuring the auth manager, connecting your identity provider, testing role access and documenting the result. Some of that work is one-time, such as the initial configuration and test plan. Some recurs, such as updating the integration after identity provider changes, reviewing group membership and keeping Airflow on a supported release line. Identity provider licensing and internal staff time are separate costs you may already carry. When you request a quote, ask the provider to separate software (none), one-time integration work and any recurring support.

What drives the cost and effort of an Airflow SSO project?

Four factors usually move the effort most. The first is identity design: a single identity provider with simple groups is far less work than several providers, nested groups or custom claim logic. The second is the number of groups and roles, since each group that maps to Airflow permissions needs an owner, a test case and a review. The third is the number of environments, because development, test and production each need configuration and validation. The fourth is compliance evidence, such as records of access reviews, role change approvals and login logging, which add documentation and sign-off steps. Other drivers include custom roles, API access for automation and the number of teams using Airflow. When you ask for a quote, request each of these factors as a separate line so you can see what changes the price.

How long does Airflow SSO setup take, step by step?

Duration depends less on a fixed number than on the order of work and how many decisions are still open. The usual sequence starts with confirming your Airflow version and auth manager, then agreeing the identity design and the group list. Next comes configuration in a test environment, followed by validation with test accounts for each role. After that, the team maps groups to roles, runs an access review and schedules a production change window. Cutover then happens, and the final step is documentation and handover to the people who will run the integration. Delays usually come from waiting on identity provider admins, unresolved group ownership or a late decision about who may use API access. Ask any provider to present the sequence and the decisions each step depends on in the written scope.

What do you need from our team before SSO work starts?

Start by naming an identity provider administrator who can register an application, configure claims and confirm group membership. The work also needs a group list with a named owner for each group and a clear statement of which roles each group should receive. You will need a test plan that lists test users for each role, including people who should be denied access. A test or staging Airflow environment that matches production closely enough to prove the design is important, as is a scheduled change window for the production cutover. Your team should also name an Airflow administrator, agree who approves role changes and confirm how automation accounts will authenticate. Finally, agree a rollback path so that access can return to the previous login method if the cutover fails.

Should we choose LDAP or OAuth for Airflow SSO?

Choose OAuth when your identity provider is a modern cloud or federated service that issues OpenID Connect or OAuth tokens and handles multi-factor authentication for you. Choose LDAP when your directory is an on-premises directory service and federation is not available or not approved for this system. Several factors help decide: where multi-factor authentication is enforced, how group membership is read, how service accounts are created and rotated, and who maintains the directory connection after go-live. OAuth usually keeps password handling at the identity provider, which simplifies the Airflow side. LDAP may suit environments where the directory is the only trusted source. Confirm which options the FAB auth manager supports in the version you plan to run, and check that your identity provider team agrees with the choice before design starts.

Does Airflow 3 use the FAB auth manager by default?

No. Airflow 3 uses the Simple auth manager by default, and only one auth manager can be active at a time. You select the active auth manager with the auth_manager option in your configuration. The FAB auth manager comes from the FAB provider package, so you install it and select it explicitly before you can use OAuth or LDAP through it. Moving from the Simple auth manager to FAB is therefore a deliberate configuration change, not a background update. It affects how users sign in, which roles they hold and how API access is authenticated, so it belongs in the test plan and change window. Confirm the exact package versions and configuration keys against the auth manager documentation for the Airflow release you run before you start.

How should identity provider groups map to Airflow roles?

Map each group to the smallest set of Airflow permissions that its members need, and document the reason for each mapping. Name groups by job function rather than by individual, so that membership changes come from your identity provider instead of from Airflow edits. Avoid mapping broad administrative groups to Airflow admin roles unless a named owner approves it. Test every mapping with a user from that group and with a user outside it, confirming that the expected access is granted and that the unexpected access is denied. Keep automation and API access on separate, scoped credentials so that a person leaving a team does not break pipelines. Schedule periodic access reviews, and record who approved each change so the mapping can be explained to auditors later.

How DeployOpen scopes, builds and hands over Airflow SSO

DeployOpen plans and implements Apache Airflow SSO inside your own infrastructure, starting from the identity provider, the auth manager choice and the roles your teams need. Each engagement is fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.

How we scope

Confirm the Airflow 3 release line and whether the Simple auth manager or FAB auth manager fits your login and role needs.
Inventory the identity provider, OAuth or LDAP options, group structure and which users need API access.
Agree in writing which roles, group mappings, API access paths and environments are in and out of scope.

How we build

Configure a single auth manager through the auth_manager option, since Airflow 3 allows only one at a time.
Map identity provider groups to Airflow roles and test each role against least-privilege expectations before cutover.
Test login, logout, token handling and API access in a non-production environment that mirrors your production setup.

How we hand over

Document the configuration, group-to-role mappings, secrets handling and the steps to add or remove users.
Provide test evidence showing which logins, roles and API calls were verified and what remains open.
Walk your platform and security teams through the runbook so they can operate the integration without us.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review identity configuration when Airflow or the FAB provider package is upgraded, since auth behavior can change.
Confirm with us in the quote which support tasks, response expectations and environments a retainer would cover.