r/IdentityManagement

OK, so I'm one of two, 2.5 senior level engineers working on all things IdP related. We handle user provisioning, sso, mfa, you name it. We've onboarded I think 250+ applications between us.

Today I was asked to help troubleshoot a simple SAML sso. Metadata was exchanged, agreements were made, settings were checked. But still, no joy.

Most likely it was a config thing on the application or sp side. I've checked the IdP config, and a colleague did the same.

So, I requested a teams session with screen sharing, perhaps I could see something their engineers missed.

First they had the wrong Metadata. Things happen. I provided the correct Idp Metadata again, and proceeded to watch them paste that Metadata in copilot with a question to adjust config based on that. Copilot spat out config, and they copy/pasted that.

An error occurred. Copy error in copilot, paste output in teams chat to me. While I watched them do it. I pointed out that this error is not saml related, but an error in their config.

Different error. Copy to copilot, paste output in teams. Error specifically pointed to something in the sp metadata. They asked me to fix that...

I gave up. I'm drafting an email to their lead dev, hoping they can actually do something without copilot.

What would you do?

Jim Routh did a series of videos with Saviynt about AI and identity. It’s not about their product. It’s more how he’s thinking about the future of IAM.

Have you seen it? What do you think?

Here’s one of them. https://www.linkedin.com/posts/saviynt\_the-routh-report-activity-7478178875403972609-G578

Coming at this from an odd direction. 15 years as a clinical imaging tech (CT/MR/X-ray) in big hospital systems, so I’ve lived inside Epic and PACS access and HIPAA from the end-user side for a long time. Now trying to move into IAM.
Finishing SC-300, planning HITRUST CCSFP next, SailPoint when I can get employer access. Home lab with Entra and Conditional Access set up.

Two questions for people actually doing IAM:

Is a clinical/healthcare background a real differentiator for healthcare IAM roles, or do hiring managers not really care?

What would you actually want to see from someone like me — specific labs, projects, tools — to take me seriously for a first IAM role?

Trying to spend my time on what matters instead of just stacking certs.

Does anyone have a One Identity Manager Course here can someone give it to me? Or the document he/she created.

Appreciate your support🙏

Thank you!

I had the basic exposure to all these domains with the tools

AM with Okta

IGA with Sailpoint ISC

PAM with Cyberark

Now i am thinking of deep-dive in one domain, can anyone help me to choose the best domain in it?

Going to share some honest lessons from our IAM unification effort, because most of what I read about this makes it sound far cleaner than it actually is.

We ran Okta, AD, and SailPoint side by side for three years before we even attempted to unify them. The result, after a full 12-month program? Better than before, sure. But not unified in any meaningful sense. Here's where we went wrong.

Our first mistake was treating this as a platform integration problem. It isn't. It's an identity infrastructure problem. The platforms actually integrate with each other reasonably well. The real gap lives in the applications, specifically the 40% of our estate that authenticates outside all three platforms. That chunk was completely invisible to the unification effort from day one.

The second thing nobody warned us about: identity orchestration is not the same as platform unification. Orchestration routes policy logic across the platforms you've connected. It does nothing for the apps that were never connected to any of them in the first place. Those apps need something that instruments at the application layer, not something that depends on platform connectivity you don't have.

So here's my honest recommendation. Before you start any unification program, audit your full application estate against your governed estate. The gap between those two numbers is the whole game. It tells you whether unification actually solves your problem, or whether it just makes the connected portion cleaner while the unconnected portion stays exactly as invisible as it was before.

What did the rest of you learn the hard way on this?

Hi everyone,

Does anyone have any training material, documentation, or video tutorials on SailPoint IIQ? I'm looking to learn topics such as implementation, application onboarding, RBAC, and other core concepts.

If you have any useful resources or can point me in the right direction, I would greatly appreciate your help. 🙏

Thank you!

Greetings all. Looking to build a lab to learn IGA flows from scratch that may become testing ground for an on-prem production deployment. From your experience which solution integrates well with Active Directory and has good documentation on setting up said integration.

After our last access review, we’re trying to tighten up identity across our whole application estate, not just the modern SaaS apps that already speak SAML/OIDC, but the older systems too. The pricing model is not helping. “Enterprise SSO” ends up feeling like a tax bracket. For modern SaaS you pay extra just to flip on SAML, and for legacy apps you pay again in engineering time or extra tools just to get them visible to the IdP at all.

The really painful part is the long tail of custom, legacy, and internal apps that don’t talk SAML/OIDC, don’t have a decent connector, and definitely don’t show up in your IGA the way the slideware suggests. You can wrap some of them with identity‑aware proxies or ZTNA‑style access, but that still doesn’t fix provisioning, deprovisioning, or access reviews. They stay partially managed at best, which is exactly where risk hides.

at the moment we’re juggling IdP‑native SSO for the well‑behaved apps, reverse proxies or ZTNA for some legacy web apps, and completely disconnected desktop or thick clients where auth is still local or bolted onto old LDAP. For a subset, the only “governance” is manual access tracking in spreadsheets because we can’t realistically refactor them this year.

If you’ve actually pushed SSO and governance beyond the low‑hanging SaaS, where did you draw the line between “we invest to fully onboard this legacy app into our IAM stack” and “we accept it as an exception with documented manual controls”?

went through two acquisitions in 18 months. each one left a different flavor of identity infrastructure chaos. been thinking through what a coherent post-acquisition identity architecture actually looks like.

the standard approach. federate the acquired IdP, migrate what you can to corporate SSO, deprecate the rest. produces a result that looks integrated at the IdP layer and is actually fractured everywhere else. the acquired estate has applications that were never governed, service accounts with no owner documentation, and auth patterns that bypass the federation entirely.

the concept that's changed how i think about this is identity fabric. governance operating as a continuous layer across the full estate rather than being a property of individual platform integrations. an identity fabric approach doesn't wait for formal onboarding to extend governance. it discovers and instruments applications directly, which means acquired estates come into scope immediately rather than sitting in an onboarding queue for 18 months.

has anyone built a genuine identity fabric across a multi-acquisition environment? curious what the architecture actually looked like and whether it changed the coverage picture.

After spending nearly 3 years building (on and off since I am doing this next to my studies) an authentication platform from scratch, I've gained a whole new appreciation for how difficult authentication really is.

What started as "I'll just implement OAuth login" turned into learning about:

• OAuth 2.0
• OpenID Connect
• PKCE
• Refresh token rotation
• Secure account linking
• Social login providers
• MFA
• Session management
• Password reset security
• Email verification
• OAuth edge cases I never knew existed

The biggest lesson was that most of the complexity isn't getting login working, it's handling every unusual edge case securely.

Building this project also made me appreciate how much engineering goes into products like Auth0, Clerk, and FusionAuth.

The project is called BlitzWare, and the goal is to provide a developer-focused authentication platform that's easy to integrate while remaining highly customizable.

I'm not posting this as an advertisement as much as I'd love feedback from other developers who have implemented authentication before.

If you've built authentication yourself:

• What was the hardest part?
• What's one thing you wish existing providers did better?

I'd love to compare experiences and hear what problems you've run into.

Hi everyone, I’m a final-year student trying to find a genuine industry gap in cybersecurity for my final project. I’m fairly solid at coding and really interested in Identity & Access Management (IAM) and Identity Governance & Administration (IGA). If you work in the field, what are the most frustrating, manual workflows or broken entitlements you deal with daily that existing tools just mask instead of fixing? I want to tackle a legitimate, real-world issue that would make for a meaningful project.

Since I have a strong development background, I’d love to actually code a tool or an open-source solution rather than just writing a theoretical paper. If there is a specific identity problem you wish someone would just build a script or micro-tool to solve, please let me know. Thanks!

~900 person org and fully remote. IT had ~60 sanctioned tools. First real audit came back with 400+. Most of it was OAuth-connected silently, "Sign in with Google" style, nobody approved any of it. Legal and Finance were the worst offenders. Cool cool…

Discovery:

1. IdP OAuth audit
Pull every third-party app consent grant out of Entra ID (Enterprise Apps > Consent and Permissions). We surfaced ~130 apps nobody had reviewed. Free, fast, almost nobody does it first.

2. CASB, deployment mode matters

• API-mode connects directly to sanctioned SaaS via API, works regardless of device or network, covers BYOD within sanctioned apps
• Inline/proxy-mode + DNS telemetry, catches unsanctioned SaaS on managed devices, blind to BYOD entirely

We ran both. Neither alone was enough.

3. Follow the money
Pull expense reports and departmental POs. Finance caught apps that never touched the corporate network, personal cards, direct vendor billing. Most teams skip this entirely.

4. App-to-app OAuth chains
Employees grant third-party apps OAuth access to sanctioned SaaS,  random tool gets files.readwrite on Google Drive or channels:write on Slack. Bypasses every network control you have. Audit OAuth scopes inside sanctioned apps, not just who's connecting what.

Control:

• Kill user-level OAuth consent: All third-party grants require admin approval. Highest ROI control, not close.
• Conditional Access: Requires a compliant Intune-managed device to issue an access token. Identity layer, not a firewall block.
• Pre-approved app catalog: Most shadow SaaS exists because employees don't know a sanctioned option is available. Killed the majority of exception requests.
• Zombie app cleanup: <2 active users, no logins in 90 days, one notice, 2-week window, revoke. Minimal pushback.

What flopped:

• Blocking without a sanctioned alternative: always gets routed around
• One-time audit mindset: new apps show up every week
• Same risk weight for everything: a dev using a niche IDE plugin ≠ Finance dumping client data into an AI summarizer

Live SaaS inventory via SMP, SSPM for posture on sanctioned apps, SSO federated across top 80 apps. Shadow SaaS still exists, goal is visibility and risk triage, not elimination.

Shadow AI SaaS is the current unsolved problem, ChatGPT wrappers, Notion AI, random copilots employees keep spinning up. CASB isn't granular enough to handle it yet. Anyone actually built solid controls around this or are we all just winging it?