#41 - IGA or IdP? Who Provisions the New App - OIM, SailPoint, Saviynt, Entra, Okta

How many of you have ever attended a meeting called New Wendell Kickoff? I mean you wanted to decline it because the quarter was already planned but couldn't because your boss was also invited. So you did and now you're watching a business take holder, genuinely excited and honestly they have earned it, share their screen and say the sentence every I am architect must have heard a hundred times. We just signed the contract, legal is done, procurement is done, we need everyone provision by end of month and now the room goes quiet but this is not a good kind of quiet. This is the kind of quiet where the I am architect and maybe that's you is running about 15 cushion advance and not one of them has an obvious answer. You have questions like does this app even support scheme should the IGA platform provision it or should the IDP provision it, does this need governance or is it just life cycle? It happens to the 200 accounts that already exists in there who approves the access and what does deep provisioning look like how fast this access have to disappear when someone walks out the door. Now here is the thing about that meeting because I have like yourself been in hundreds of those meetings it happens in every enterprise and when it doesn't happen when the app just quietly goes live without anyone asking those questions you haven't skipped the cost you have deferred it and I promise you it comes back later with the interest and we have a name for that that's called audit debt. In the last episode we talked about scale the protocol that finally made for reasoning grow up. If you haven't heard it I would strongly recommend you to go back and hear it. And if you are familiar with the scheme you know that we have built the pipes right today we answered the question scheme never answers when a new application shows up who actually pulls the trigger who provisons it how and why the same way every single time. I am Rohit this is identity navigator let's get into this. So before we build the decision tree let's set the scene because the tools you have determined which decisions are even available to you. We have talked about we are talking about an architecture pattern that's extremely common in the enterprise right now there are three layers to it. Layer 1 is your IGA platform your Oracle identity manages or sale points or savings of the word. This is your governance layer city hall if you want to and matter for join a mover labor orchestration, local management, access request for close, access certifications, permits, records, inspections. Layer 2 is your identity provider your Microsoft Indra, ID or author which is authentication and directly layer the SSO, MFA, right the utility company doesn't ask why a building needs power it just connects it this is like a utility company and layer 3 is your application being onboarded with its own capabilities its own user model and let's be honest it's own opinion about how it wants to receive identity data now here is what makes this genuinely interesting and it's the tension at the heart of the whole episode in this stack you have two systems that can provision the target application the IGA platform can do it the ID can do it and they speak the same protocol that's the skin story from last time but they have completely different strengths different speed and different ideas about what done means your definition of done differs system to system here so if the last episode answered how does the account get created skin standardize is standardized boring beautiful but what skin never answered is who decides and who is accountable now that's not a protocol question that's an architecture question an architecture question deserves better than whoever speaks of first in the meeting because that's how most team actually decides this day got fee president the loudest voice in the room and they decided differently every time which means every app onboarding is a snowflake and every audit becomes a scavenger hunt this is also compounded by the principle of this application onboarding factory that every vendor is trying to sell you today because they try to put things into buckets which sometimes do not belong together sometimes your business analyst or your product people need to be updated or educated as well and because the identity architect cannot be in every room where these meetings happen so there are a lot of anti patterns here and here is the uncomfortable part both defaults fail pick the IDP because it's fast and it fails fun way and pick the IGA because it is thorough and it fails a completely different way you usually don't find out at at go live you find out 18 months later in an audit room or an incident review so I want to show you today exactly what that looks like so before the framework let's talk about two stories quick ground rules before I start though both of these stories are composites details changed companies blended pattern 100% real if one of them sound uncomfortably like your organization that's not a coincidence that's the point so story one is about a midsize company that sciences sales engagement platform you know the time it it plugs into the CRM tracks outraged as the sequence the sales VP wanted live yesterday and the identity provider admin who is sharp helpful slightly overworked looks at the request and season easy when the app has a prebuilt integration sitting right there in the octa catalog skin support ready to go so that afternoon they do what the two links make easy clip on provisioning pointed at a group and everyone in the sales org gets access and they go home feeling like a hero and honestly take the kind of for 200 people provisioned in a day no ticket no waiting the business is thrilled this is exactly what modern identity tooling is supposed to feel like and our 18 months pass the group rules gets edited twice by two different admins for two different reasons nobody actually wrote down so the contractors get nested in and the app itself quietly grows up it starts sending customer contact data back from the CRM real names real emails real deal information the sales productivity tool is now functionally a system holding customer PII which is exactly when it shows up in the sock to scoping call and the auditor asked the question auditors always asked so show me who approved access to this application for these 412 users and when and the answer that true complete honest answer is a group rule somebody wrote no approvals no request no certification history no manager has ever attached it that their people need this access because the access was never granted to anyone it just matched a filter so there is silence in the audit room and that is the audit debt that I was talking about in the cold open this is an audit debt with interest and here is the part I need you to sit with nothing malfunctioned here the IDP did exactly what it was configured to do past reliable and flawless the engine didn't fail the assignment did nobody asked that this nap needed governance because there was no moment in the process for that question lived now I told you that both defaults fail so this is the second story about default to failure ok so different company opposite instinct this one runs a serious IGA program and when they onboard their financial reporting system they do it right they did it right I mean genuinely right access request with approvals role model quarterly certifications where manager actually the view instead of rubber stamping every account traceable to a decision if the auditor from story one or into this room a team would smile and pull the report the IGA platform own provisioning and to end including the provisional on its scheduled task cycle because that's how these platform works and event lands the next life cycle tasks. set up and provisioning executes. And then comes a Friday. It's an unfortunate Friday because an employee is terminated for costs. They are bogged out of the building at 9.15 in the morning. HR does everything by the book. The termination hits work day before 9.30. At 10 o'clock, the security team asks the question, security team always asks on for cost termination is the excess cut. And the honest answer is it will be. It was the life cycle tasks run on a schedule. The termination has to get picked up, processed, propagated. The actual deprovision lands in the financial system a little after two in the afternoon. That is nearly five hours valid credentials to a financial system and by someone who was escorted out of the building by everyone whose job is to worry worried. And if anything bad happened in those five hours in this composite, no. And you can also talk about a difference in depth or zero in your trust architecture here. But in some version of this story out in the while, maybe yes or definitely yes. But the head is the thing, it almost doesn't matter. Because in the incident review, nobody could defend the window. And when somebody in that review asked, wait, couldn't we have just disabled their SSO account immediately? The room went or should have gone quiet because yes, obviously that is a great control. And it got discovered in a retro instead of designed into an architecture. And again, nothing malfunctioned. The IGA did exactly what it was about to do, governed, auditable, thorough. So the engine didn't fail the assignment gate. Nobody asked how fast access needed to die because there was no movement in the process where that question lived either. So you only have seen two failures in one root cause. Let's look at what just happened. Team one picked the fast engine and lost the paper tray. Team two picked the thorough engine and lost the clock. Opposed it choices, but same disease. A same disease. In both rooms, the who provisions, this decision was made once by instinct, by whoever's default one. And it was never examined again. Now neither engine was wrong, neither team was careless. These are good tools operated by good people. The failure lives entirely in the announced questions. Hold onto the shape of this because it comes back at the end of the episode. I'll hopefully tie it all back together because the IDP is fundamentally a speed layer and the IGA is fundamentally a governance layer. Assign an app to the wrong layer or the one layer where it when it needed both and you don't find out at go-life. You find out 18 months later in an audit room or an incident region. So one more piece of context and I'll keep it brutally short because the scheme episode already toured this landscape with us on this in much more detail. Your specific IGA plate form tells the decision. So your OIMS 20 years of workflow orchestration depth, multi-step approval, custom logic, it will model anything. But a connector catalog that doesn't move access speed and change or changes that cost your development cycles. Singapore identity IQ built around the identity queue when unified view of every account and entitlement of person holds aggregated from every connected system with governance depth as the whole point. And its skin connector keeps every provisioning decision and audit tray inside the platform at the price of real administrative overhead. You'll see we end is your cloud first with a large pre-built application catalog with connectors attribute mappings entitlement schemas ready to go and unusually deep application level governance out of the box. That's a tool though longer version in the show notes because the important thing is in the vendor comparison. It's when the framework says the IGA must be in the chain your IGA is strength and cost shapes how you wire it. And this is another anti-packed and that I've seen with many application or identity architects is that they treat all of these tools as same. But all of these tools internally have their own strengths and weaknesses. So even though they're all IGA tools, you have to identify the differences that at your architecture decision should be because of the difference in the tools. So keep these two stories on your pocket and let's talk about the framework that I have built into words. Here is how I want you to think about this. Excuse me. Every new application is a job applicant. It wants a role in your environment and your job is to interview it. So five questions are in order because each answer routes is somewhere specific. And by the end of the interview, the architecture chooses itself. The question one. Do you speak scheme 2.0? This is the gate question. Check the vendor's documentation. Look for scheme in the admin or developer docs. Look for endpoint like forward slash scheme forward slash me to and check whether the vendor publishes an integration in the entra or attack catalogs. If they do, scheme support is usually spelled out right there. And if the answer is no, stop. You're no longer making a scheme decision. You're making a connector decision. Your IGA platforms native connector, a rest connector, a flat file integration or a custom built. The IDP provisioning path is largely off the table because modern IDP provisioning is a scheme based. Make a note, slag it with the vendor as technical debt politely, but in writing and move on. Now, if yes, so go to the next question. And if you're wondering why scheme is the gate, that's the entire previous episode. Go listen to it. I'll be right. So question 2. Does access to this thing requires governance? And I mean governance specifically, not vaguely approval workflows, access certification campaigns, role model links, separation of duties, enforcement. Here's the list list test that I use. Imagine the sort to auditor across the table asking, show me who approved this user's access to this application. And when? Can you answer that? Governance isn't a feeling. It's a paper trail. If the answer is yes, and for anything touching sensitive data, financial data, the II or regulated content, it should be yes. And the IGA platform must be in the provisioning chain. They can take two shapes. The IGA provisions directly through its a scheme connector or the IGA controls who gets assigned to the application in the IDP. And the IDP pushes the scheme. Either way, governance lives in the IGA. And if the answer is no, this is your low sensitivity, productivity, tool, collaboration apps. The stuff where access is broadly available are kind of like birthright, the IDP can own provisioning end to end. Either way, go to the next question. So question 3. Is a group enough or does this app have rooms inside? That is your fine grain and coarse grain authorization? So group-based access is a front-door key. You're a member of this center or a group. Therefore, you get in that is binary, that is clean. The IDP assigns the group, the scheme push creates the account. Now entitlement tiers are different. That's when the app has room inside. It rolls profiles, permission sets, license type, data across access codes. And which room you can enter, matters enormously, enormously. In Salesforce, the gap between a system administrator profile and a read-only profile is a chance. In service now, an ITSM agent and an end user lives in different universe. In slow-pay, which role you hold literally decides which data you can query. It's a front-door app and low sensitivity. Sensitivity, if your IDP owns proofies thing, configure a scheme in Entra or Octa, define the group assignment logic and then just be done with it. But if there are rooms inside, the IGA platform has to be in the chain. Because those entitlement needs to be requestable, approval and certifiable. The IDP cannot model that. The IDP sees the door, the IGA needs to see every room behind it. Some of you might be picking up on this, where as soon as a new application has to be onboarded, you directly jump into the type of connector. You have a scheme connector and rest-based connector and custom connector. So everything maps to the application on onboard and factory that either you have created or you have bought. But there are decisions that needs to be made before this. And this is what we are trying to I don't know. how those seasons are made. So let's go to question number four. But someone leaves how fast the taxes have to die. And ranking this is like the most obvious question but this is the question that gets underweighted on the whiteboard and this becomes a crisis more often than not during an incident. So ask it out loud when a user is terminated how quickly must their access to this application be revoked. Then highly sensitive application your financial records, customer PI, source code, security tooling, the answer might be within one hour of the termination hitting the HR system. Now the uncomfortable follow-up can your IG platform actually meet that number? One and sales point both runs scheduled provisioning tasks depending on configuration. A termination event might not propagate for 30 minutes, two hours or longer. Meanwhile enter ID scheme provisioning cycle runs roughly every 30, 20 to 40 minutes, though you can trigger on demand provisioning for a specific user as well. Author is near real time, typically under five minutes from a lifecycle event. So if the deprovesing speed is critical and your IG cannot hit the SLA, you build a compensating architecture, then there are three options. So let's start with the cleanest option first. So the one, the ID file real time API equal to enter or the on termination and the IDP immediately pushes the scheme deprovesing. Number two is your ID, a deprovesing the users enter or octagon directly, disabling their identity, provide their identity or a IDP identity. Sorry, I said it out. We are disabling their IDP identity blunt, but it cascades to every skin connected and associated application advance. And number three option or the third option is both the IG and the IDP keep deprovesing hooks into the app. The ID handles components and the IDP handles speed, more moving parts, more to maintain. I typically do not endorse this architecture, unless there is a very specific justification for that, but in all three, remember the role IG and makes a decision and IDP delivers the punch. So the fifth question right is who is already living in this app and this question isn't about the future state architecture, it's about the go live risk. Almost every application being onboarded into a govern provision, provisioning model already has users. They get in somehow manually through the app's admin console, through a previous integration that's now being retired. And if you just flip on skim provisioning over the top of them, here is what happens. Skim tries to create account for everyone it believes should exist. Exist an account with slightly different users name, different email formats, different attributes values, duplicates, conflicts, error, a very bad first week. So before go live, you export the existing user population from the application, match it against the IGA identity queue or your IDP directory, you will end up with three buckets, your mass identity, your unmasked but active identity and you should investigate them or your unmasked with no recent logins and those are your offer accounts, right. So it's archaeology for construction, it's not glamorous but it's absolutely mandatory and I've seen very very few people do it. So that's the interview, five questions in order and now let's run a real candidate through it, right. Let's let's get to it. So now let's get back to the meeting and now it's yours and you are you have all the information that we have just discussed. Let's say your stack is sale.identity IQ plus enter ID and the app on the table is let's pick an app that everyone has sales force and run the five questions out loud, okay. So Q1 does not have the quarter one question one does sales force peak skin 2.0? Yes, well documented skin 2.0 endpoint supporting users and groups and both IDPs ship pre-built integration, enter as an enterprise application template for sales force and also opt as a sales force connector in the OIN. So nobody is building anything custom here, okay. That's cool. Question two, the sales force access requires governance and answer is almost certainly. Two, it's your CRN, trust my data, my plan data, contract value, account relationship and most enterprises sales force sits squarely in soft to scope. So managers need sweat as 10, you know everything needs to be there. So you are not provisioning sales force purely of entire group membership with no governance layer, okay. Because we need governance here. Question three, are there rooms inside, right. Please talk about fine-grained. So there are rooms obviously in sales force. We have profiles like system administrator and standard users and read only your permission sets tag on top of profiles, your license type, sales force, sales force, platform, community and the distance between a system administrator profile and a read only profile with the no permission set is not a nuance. It's everything versus look, don't touch. So these entitlements needs to get modeled in sales point. They need to be requestable, affluent, certifiable. So honestly check point and this is where Savian would head you a handy way head start. It's sales force connector, pre models, profiles and permission sets as governed entitlement out of the box. In IQ, you are building that entitlement schema yourself. So if your team knows IQ, it's not hard, but it's work Savian gives you for free, essentially. Next. How fast does access have to die? Say your security policy reads, terminated employees lose sales force access within four hours of termination in workday. Now security policies are never this nuanced, but you need to understand your critical applications or top tier applications and API data. So you need to do some thinking of your own or reach out to privacy or a legal folks to understand this. So can IQ on a standard schedule provision cycle? A provision cycle make four hours probably, but probably is not an architecture. I run the math on your actual task schedule. If your lifecycle events task runs every two hours and there is a processing time on top of that, four hours is tighter than it sounds. The safer build, configure IQ to fire an immediate provisioning action on termination events. So I give support to this through the cycle events triggers and instead of waiting for the next schedule run, so you have to test it out. Measure the really laps time from workday terminations to sale force account deactivation and write that number down because that number is going to appear in your sock to audit. And even if that doesn't clear the bar, add the belt to the suspenders on termination. IQ disable the user and track out immediately, SSO goes dark. Even if the skim deep provision lags a few minutes, the person cannot authenticate into sales force or anything else, honestly. Let's. Who's already living in sales force? Everyone's sales force has been in the building for years, accounts are created by admins, by hand, by an old integration, nobody will admit to owning. So you run the day, export all active users, cross-reference them against the sale point identity queue, match on email and flag anything that doesn't match. Matched account, link them in sale point and stamp the sale point identity ID as the external ID in the sales force user account. Now IQ knows the account exists and it wants it. If you find unmasked but recently active, you have to investigate. These are missing identities or legitimate service accounts. If they are unmasked and dormant, and these are your unfriend accounts onto the clean up list, clean house before you turn the automation on. And the final architecture, picture it top to bottom. Work this sits at the top as the HR system of record. Everything flows into sale point identity IQ. This is the brain. Journal mover Lea was orchestration, the sales force, role model, profiles and permissions, sets model, there's entitlements. Your access reviews and approval work flows and quarterly certifications in light cycle triggers harmed on terminations. Out of the IQ, two paths run simultaneously. Path A governed provisioning, IQ pushes came to straight to sales force, creates, states deactivates accounts, assign profiles and you have a path B which is your safety net on termination, IQ disables the entire account and sales force SSO slams shut. Here's a sentence to remember, sale point owns the governance and the provisional record and entries the authentication gate. Skin is the delivery So these tools saw three tools, three lanes, and nobody's doing anyone else's job. Now, around 50 times and pattern appears, right? When you do it for 10 times or 20 times or 50 times, you will notice something. The answer is start to rhyme. And those rhymes are your architecture principles, and they are worth naming out loud, because they belong in a document and not in one architect's head. Pattern 1 is sensitive apps, live in IGA, productivity apps, live in the IDP. So you CRM, your ERP, your financial system, your data warehouses, through the IGA plate on no exceptions. Governance is on negotiable or systems that touch regulated data or create financial risks. With collaboration tools, your project occurs, your internal VKs, the IDP provisioning layer is satisfying. Full IGA governance on confluence or Miro is a suit of armor for a pillow fight. But draw that line explicitly, write it into your architecture principles documents. Ambiguity is exactly how hand apps end up in wrong lane. The pack and two that for demos is the IDP is the speed layer, and the IGA is the condenser layer. So your IDP is a near real-time event processing, sub-five-minute-provising cycle. But the IGA platform is thorough. Pattern 3 that would emerge is reconciliation is not a one-time event. You reconcile that onboarding, good, not do it quarterly, at a minimum. SAS applications accumulate accounts that never touch your governance flows. API integration, spawn service accounts, vendor create admin accounts for supports, and employees self-register on trial instances. And by the way, this is actually what makes access to certifications real. The certification campaign asks management to review their team's access. But the aggregation job is what guarantee is the reviews complete. So in closing, let's go back to the meeting where it all started. I told you I'll tie it all back. The one that opened with we signed the contract provisioned every one by end of month, and then there was silence. It doesn't have to end in 15 simultaneously announced questions. It can end with one sentence. When it through the framework, you will have an architecture recommendation in a week. 5 cushions as the app speak skip. Does access requires governance? Are there rooms inside or is a front door key enough? How fast that access have to die? And who is already living in there? Answer those 5 honestly in order and they route you to the right architecture. I promise you every time. Now the tools matter. OEMS work flow depth, sales points, governance maturity, savings, catalog breadth, entras, provisioning muscle, optas near real time reflexes. But here is a distinction that makes this framework portable. The tools determine what's available to you. The framework determines what you choose. So build it, document it, and use it every single time. In the next time that meeting lands on your calendar, you will walk in with an answer instead of 15 questions. You can reach out to me on LinkedIn or you can send me a meme in. Both of these information I'll put in the show notes. Thank you for listening. This is Rohit for Identity Napping It.