IAM / SSO Engineering
Enterprise authentication
Supported enterprise IAM platforms and delivered 15+ SAML/OIDC integrations for a 1,200+ user environment.
The problem
Every application interprets identity a little differently: which attribute is the username, what a role claim means, how long a session lives, what happens when the assertion arrives ten seconds 'early' because of clock drift. Multiply that by an enterprise app portfolio and SSO stops being a protocol exercise and becomes a coordination and troubleshooting discipline.
The work behind this page: administering enterprise identity providers for a 1,200+ user environment, leading an org-wide OneLogin rollout in phases, and delivering 15+ SAML 2.0 / OIDC integrations — plus the unglamorous follow-through of claims mapping, certificate renewals and failure-path debugging that keeps them working.
The approach
Define trust precisely before touching configuration: entity IDs, redirect URIs, certificates, attribute contracts. Most SSO outages trace back to an identifier or certificate detail, not the protocol.
Test failure paths as deliberately as the happy path — expired assertions, wrong audience, missing attributes — and share ownership with application teams, because the IdP config is only half of every integration.
The three diagrams below are generic, educational versions of the flows this work is built on. They contain no real tenant configuration, tokens or secrets.
My role — IAM administration, application onboarding, policy configuration, claims troubleshooting and cross-team collaboration.
How it works
SAML 2.0 SSO — how the trust actually works
Generic SP-initiated flow. The point most explanations skip: the application validates the assertion — it never simply trusts it.
01Access attempt
The employee opens the application. No session exists yet, so the app hands authentication to the identity provider.
Select any node in the diagram to inspect it.
- Person
- Connected system
- This project
- Internal layer
- Success
- Info
OIDC — authorization-code flow
The generic modern flow: the browser carries only a one-time code; tokens travel on a back channel. No real tokens or secrets shown.
01Authorization request
The app sends the employee to the identity provider to sign in.
Select any node in the diagram to inspect it.
- Person
- Connected system
- This project
- Internal layer
- Info
- Success
JML — the lifecycle behind the login
Joiner, mover, leaver: access follows the person's status automatically instead of waiting for tickets.
01Joiner
Day one: the new hire's status flows in, rules compute their access, and their applications are ready — no ticket chain.
Select any node in the diagram to inspect it.
- Connected system
- This project
- Internal layer
- Success
- Info
- Skipped
Architecture
The platform view
The sanitized shape of the environment this work runs in — generic by design.
- Person
- This project
- Internal layer
- Connected system
- Data at rest
- Person
- This project
- Internal layer
- Connected system
- Data at rest
The federation edge is real, résumé-supported work: integrating an external Keycloak-style identity provider with the primary IdP — login URLs, redirect URIs, client credentials and token mappings — so users from another trust domain authenticate cleanly. The diagram stays generic; no tenant names, endpoints or credentials are shown.
Key engineering decisions
- Application onboarding
- MFA policies
- Group-based RBAC
- JML access
- Token & claims troubleshooting
- Role provisioning
Switch to the technical view for the engineering trade-offs behind these.
Challenges & limitations
- These diagrams are educational versions of standard protocols — deliberately generic, with no real tenant configuration, tokens, secrets or customer details.
- This is engineering with enterprise IdP platforms (Okta, OneLogin, Ping), not a claim of having built them.
- Automation depth varies by application: the JML pattern is real, but not every connected app has identical provisioning and deprovisioning mechanics.
- Metrics on this page stop at what the résumé supports: the OneLogin org-wide rollout, 15+ SSO integrations, and a 1,200+ user environment. No further numbers are claimed.
What I learned
Reliable SSO is a discipline of precise identifiers, deliberate failure-path testing and shared ownership. The protocol is the easy part; the trust configuration around it — and the people coordinating it — decide whether sign-in works on the day the certificate rolls.
Project status
Ongoing IAM engineering at Priority Technology Holdings: identity-provider administration, phased OneLogin rollout, 15+ SAML/OIDC integrations, MFA and adaptive policy, JML lifecycle automation, federation, and authentication monitoring.