Back to Portfolio

Independent Portfolio Project · Identity & Security Operations

Identity & Security Operations
Employee Access Lifecycle Assistant

A lean, interview-ready case study for a simulated employee role-change engagement across HR, IT, security, and application owners: one employee role change, from HR signal to verified and auditable access.

TriggerEvaluateApproveProvisionAudit

Status: In Progress

This case study is being built in public. This page documents the discovery, architecture, and safeguards work completed so far; the live demo and technical walkthrough are still in development. This is an independent, fictional portfolio exercise based on public identity-lifecycle patterns. It does not represent Okta, Microsoft, any employer, or any proprietary architecture or security control.

The problem

AtlasPoint Software is a fictional, 900-person B2B software company with a cloud HR system, an identity provider, a service desk, and roughly 35 commonly managed SaaS applications. Role changes often add new access without consistently removing old access. Application owners use different approval paths, and evidence of what happened is scattered across tickets, emails, and administrator logs.

Every number below is an illustrative assumption to validate in real discovery, not customer evidence.

65

Joiner, mover, and leaver events per month

7

Downstream access decisions per event

48 min

Manual IT effort per lifecycle event

14%

Require manager, security, or app-owner review

The solution concept

The demonstration centers on one employee changing from Sales Development Representative to Account Executive: a visible state machine that makes approval, partial success, verification, retry, and audit behavior understandable to both technical and nontechnical stakeholders.

  1. 01A synthetic HR event arrives and is matched to an immutable employee identifier and source record.
  2. 02Required attributes are validated, then the policy engine calculates the grant, retain, remove, and prohibit set for the role change.
  3. 03Standard changes route to manager approval; risky or separation-of-duties combinations route to mandatory security review.
  4. 04An authorized approver approves the exact access difference, binding the decision to a policy version and a decision hash.
  5. 05At the effective time, mock connector commands execute idempotently against identity, SaaS, and service-desk adapters.
  6. 06Downstream state is verified and confirmed before the event is marked complete; partial failures stay visible and retryable rather than silently succeeding.
  7. 07If HR cancels or changes the role move before the effective time, the prior approval is invalidated and re-evaluated. A stale approval is never executed.

Lean architecture and boundaries

Say every limitation plainly. The project demonstrates policy design and workflow reasoning, not production identity security: no passwords, no production directory, no live credentials, and no claim to be an identity provider or governance platform.

FastAPI App

State machine, policy engine, and approval service.

Single process; synthetic tenant.

Policy Store

Versioned RBAC, attribute, and separation-of-duties rules.

Deterministic JSON rules, not a policy editor.

Mock Connectors

Identity provider, SaaS apps, and service desk adapters.

Least-privilege test accounts, no production tenant.

Audit Store

Append-only history of inputs, decisions, approvals, and outcomes.

No production retention program.

Optional AI Adapter

Classifies free-text manager justification and drafts rationale.

Advisory only; never authoritative over access.

Review UI

Shows the access difference, risk evidence, and approve/reject controls.

No production operator authentication.

AI decision contract and safeguards

Use deterministic policy for access; use AI only where judgment is bounded. A language model may help interpret or explain, but it never becomes the authority that grants access.

The safest default for a mover is not “keep everything and add more.” It is “re-evaluate every entitlement against current justification.”

How this will be demonstrated

The finished deliverable pairs a seven-minute customer-facing demo (the buyer's operating problem, one complete mover event, a pressure-tested risky scenario, and a proposed next step) with a twelve-minute technical walkthrough (event contracts, state, policy, approval, adapters, reliability, audit, the AI boundary, and the production path). It ships alongside the presales artifacts that support a real proof-of-value: a discovery guide, a stakeholder map, a security readiness brief, and a POV charter with a scorecard.

Discovery GuideStakeholder MapSecurity ReadinessPOV CharterDemo Script

Following along?

This build is happening in public. Reach out if you'd like to talk through the approach, or check back for the finished demo and technical walkthrough.

Contact Me