How I automated employee onboarding and offboarding with Okta, Jira, and Airflow
Building a real enterprise identity automation pipeline for $10/month
The problem
Every IT and IAM team faces the same painful reality: onboarding a new employee means manually creating accounts across a dozen systems. Offboarding is even worse — miss one system and you've got a security gap. I wanted to automate this entire lifecycle using the tools I work with every day: Okta, Jira, Apache Airflow, and Slack.
The goal was simple: when a user is provisioned in Okta, everything else should happen automatically. When they leave, everything should be revoked — with a full audit trail in Jira.
The stack
| Component | Tool | Cost |
|---|---|---|
| Identity Provider | Okta Integrator Free Plan | Free |
| Workflow Orchestration | Apache Airflow 2.9 (self-hosted) | ~$10/mo GCP |
| Ticketing | Jira Software (Automation Hub) | Free |
| Notifications | Slack Webhooks | Free |
| Domain | inguva.dev | $10/yr |
Architecture
Here's how the full pipeline works:
New hire added in Okta
↓
Okta SCIM → Airflow user provisioned
↓
Airflow DAG triggered (okta_onboarding)
↓
Jira ticket created (AUTO-XX) with full checklist
↓
Slack alert sent to IT team with ticket link
For offboarding it's the reverse:
Employee departure confirmed
↓
Airflow DAG triggered (okta_offboarding)
↓
Jira ticket created with revocation checklist
↓
Slack alert with orange warning to IT team
↓
Okta account deactivated via SCIM
Building the onboarding DAG
The onboarding DAG accepts a JSON config with user details and does three things: creates a Jira ticket with a full onboarding checklist, sends a Slack notification with all the details, and logs everything for audit purposes.
The Jira ticket includes a structured checklist covering every system that needs provisioning:
Okta account created
Jira/Confluence access granted
Airflow access granted
Slack workspace invited
Laptop provisioned
Equipment shipped
Day 1 schedule sent
Triggering it is as simple as running:
airflow dags trigger okta_onboarding \
--conf '{
"username": "john.doe@inguva.dev",
"full_name": "John Doe",
"department": "Engineering",
"start_date": "2026-03-16"
}'
Within seconds, a Jira ticket (AUTO-3) is created and the IT team gets a Slack message with all the details and a direct link to the ticket.
Building the offboarding DAG
Offboarding is where security really matters. A missed deprovisioning step means a former employee could still have access to sensitive systems. The offboarding DAG creates a comprehensive revocation checklist in Jira:
Okta account deactivated
Jira/Confluence access revoked
Airflow access revoked
Slack deactivated
Laptop return scheduled
Data backup completed
Exit interview scheduled
Final paycheck processed
The Slack notification uses an orange color to signal urgency — the IT team knows immediately that action is required.
The SCIM bridge
What makes this particularly interesting is the custom SCIM bridge I built. Okta's SCIM 2.0 provisioning protocol sends HTTP requests to provision users, but Airflow has no native SCIM server. I wrote a lightweight Flask app that:
Receives SCIM requests from Okta
Translates them into Airflow REST API calls
Creates or deactivates users in Airflow automatically
When you assign someone to the Airflow app in Okta, they appear in Airflow within seconds — no manual steps required.
What I learned
The most valuable insight was understanding the difference between authentication and provisioning. SSO handles authentication (can this person log in?) while SCIM handles provisioning (does this person have an account?). Most teams get SSO right but forget about automated provisioning, which means users get created manually and — critically — often don't get cleaned up when they leave.
Building the SCIM bridge forced me to read the actual SCIM 2.0 RFC and understand exactly what Okta sends over the wire. That knowledge transfers to any identity system, not just Airflow.
The other big takeaway: Airflow is an incredibly powerful orchestration engine for IT automation, not just data pipelines. The DAG model — where you define tasks, dependencies, and failure handling — maps perfectly to onboarding and offboarding workflows.
The outcome
Onboarding time reduced from manual multi-step process to one triggered DAG
Full audit trail in Jira for every onboarding and offboarding event
IT team gets instant Slack notification with all details
Zero missed deprovisioning steps — the checklist is always generated
Entire stack runs for ~$10/month on a GCP e2-medium VM
What's next
The natural next step is triggering these DAGs automatically from Okta webhooks — so the moment a user is activated or deactivated in Okta, the DAG fires without any manual trigger. I'm also planning to add an access review DAG that periodically checks for dormant accounts and flags them for review.
If you're building identity automation or want to talk IAM engineering, reach out at chander@inguva.dev.
Built with Apache Airflow · Okta · Jira · Flask · GCP · Slack · inguva.dev