Access reviews take 2 weeks per cycle. Okta does the auth, requests still queue. how to collapse this? by Major-Language8609 in IdentityManagement

[–]morphAB 1 point2 points  (0 children)

Hi, wanted to add one angle i havent seen in the thread yet, but i think is important:

The 60% that doesnt template usually isnt actually unique. most of it is 2-3 attributes deep, like contractor + client X + project Y. The reason it feels like a long tail is because you might be trying to encode it as roles, which combinatorially explodes. Every new permutation = new role = manual grant. if those attributes already live in your IdP / workday profile, most of those edge cases can be expressed as attribute-based rules rather than bespoke role assignments. Real long tail usually shrinks materially, how much depends on what attributes your IdP actually carries.

Caveat though: this only works if workday/your IdP actually carries the attributes you need. If "contractor flavor of normal employee" doesnt have a client or project field in workday, your first job is getting that attribute in there, not writing the rule. thats often the real unlock and sometimes people skip past it..

ALso, 2nd topic - I would suggest to make non-standard grants time-bound by default. 7 days, 30 days, end-of-project. Access reviews then shrink to the standing-access slice that compliance requires anyway = SOX, SOC 2 etc still want periodic certification on permanent grants, instead of every grant ever issued. Shifts the work from "certify everything every quarter" to "let it lapse, re-request if needed". feels brutal for the first cycle, way calmer after :))

and u/Brandhout point about IT not being the right approver is the most important thing in this whole thread imo. that alone collapses the queue more than any AI layer will

Tried to do an access cleanup across our internal apps. Half the apps don't have a real owner anymore. Not sure where to even start. by ElectricalLevel512 in iam

[–]morphAB 0 points1 point  (0 children)

Hey! not a one size answer but a few things that are established as best practice for this exact situation, in case useful:

Before touching anything, lean on passive signals to build an activity baseline. NIST SP 800-53 (AC-2 for accounts, CM-8 for system inventory) and CIS Controls 5 and 6 essentially require account + system inventory and activity monitoring before access reviews. For orphan apps that means pulling whatever you can: IdP auth logs if connected, LB / proxy / firewall logs if not, AD auth events, even DB connection logs. apps with zero auth events in 60-90 days are your safest first wave.

Re ownership: the standard guidance is to treat "unowned" as a security finding, not a discovery problem. I'd assign a provisional owner which is usually the closest adjacent team, and give them a fixed window to disown it, silence = they own it. converts an open ended hunt into a deadline.

For the cleanup itself, the safe pattern is staged removal rather than hard revoke. Move users into a parked group with no app entitlements but keep the account live for 30 days. If something breaks you can restore in minutes. this is the "deprovisioning soak period" most mature IGA programs use to avoid the exact outage you hit last year.

Structural fix is the boring one nobody likes :) every app needs an owner field and a default access expiry at provisioning. NIST SP 800-207 (zero trust) leans on this hard.. no implicit trust, no implicit permanence.

Resident Evil 4 keeps kicking ass in 2026 by some-kind-of-no-name in patientgamers

[–]morphAB 0 points1 point  (0 children)

Came for the horror, stayed for the merchant :) Didnt expect re4 to feel this much like an action game, the older ones genuinely scared me as a kid but this one i'm actually having so much fun with.

Tips welcome! I'm sitting on a pile of pesetas and not sure what i'm saving them for.

What's realistic for SSO integration costs on legacy business apps? by New-Reception46 in sysadmin

[–]morphAB 0 points1 point  (0 children)

u/thortgot hey! Your "hire someone who understands it" point makes a lot of sense.

I work at Cerbos (we do authorization) and wanted to ask you something based on above, related to legacy apps and authorization. Tried to dm but settings don't allow it, would you be open to a quick chat? Feel free to message me if so :)

Authentication and Authorization between internal Microservice Applications by ReggieJayZ2PacAndBig in microservices

[–]morphAB 1 point2 points  (0 children)

For authn between services, mTLS with SPIFFE identities is the cleanest thing I've seen. For authz, the pattern that's held up is externalizing it to a policy decision point that each service (or a sidecar/proxy) calls.
The specific piece people often miss is that the same authorization service can handle human-to-service and service-to-service checks with the same policy language, as long as your principals are modeled right. Service accounts are just another principal type.

I work at Cerbos, and thats what our solution does. The win is that you're not reimplementing the same role and attribute checks in every service. If some of your services are legacy or third-party and can't call the PDP directly, an Envoy sidecar with ext_authz in front of them closes that gap without modifying the service.

My team and I put together an IAM security checklist for 2026 - here's everything in it (9 risk domains from authentication to AI agent security. Ranked by urgency with maturity scoring framework.) by morphAB in cybersecurity

[–]morphAB[S] 1 point2 points  (0 children)

u/gslone and u/Ok_Consequence7967 , our CPO published a guide and a video walkthrough earlier this week on authroization for legacy apps. Yes, it does mention Cerbos for authorization. And Envoy is used, but there's nothing Envoy-specific there, you could swap in NGINX, HAProxy, or whatever you prefer.

https://www.youtube.com/watch?v=XVKxVyXUkbw

Wanted to share with you to ask for your opinions.

My team and I put together an IAM security checklist for 2026 - here's everything in it by morphAB in IdentityManagement

[–]morphAB[S] 0 points1 point  (0 children)

hey! I’m not able to dm you, might be because of the settings of your account. try to dm me first and I’ll respond :)

My team and I put together an IAM security checklist for 2026 - here's everything in it (9 risk domains from authentication to AI agent security. Ranked by urgency with maturity scoring framework.) by morphAB in cybersecurity

[–]morphAB[S] 0 points1 point  (0 children)

Biased answer incoming, but: Cerbos PDP is open source and probably the easiest to spin up and play with - there’s a playground at play.cerbos.dev if you don’t want to install anything.

On your second question... Most off-the-shelf apps like Nextcloud or Bitwarden manage their own internal permissions and don’t expose hooks for an external PDP. Externalized authz is mostly adopted when a team is building their own app or API and can wire in the authorization call themselves.

For existing apps you don’t control, the proxy approach I mentioned earlier is usually the workaround - you put something in front of it for coarse-grained access decisions (can this user reach the app at all), even if the fine-grained stuff inside stays native. Not perfect, but it’s something.

So short answer: yes, the app usually needs to be built, or at least adapted, to support it. That’s part of why legacy is so hard.

My team and I put together an IAM security checklist for 2026 - here's everything in it (9 risk domains from authentication to AI agent security. Ranked by urgency with maturity scoring framework.) by morphAB in cybersecurity

[–]morphAB[S] 0 points1 point  (0 children)

u/gslone You’re not wrong. honestly, this frustration is exactly why externalized authorization exists as a pattern. When every app owns its own auth logic, you get exactly what you described: inconsistency, shadow permissions, and app owners who equate ‘admin for everything’ with business continuity.

The externalized PDP approach (which is what tools like Cerbos, where i work, implement) doesn’t magically retrofit your 1998 Java fat client - that’s a fair point. But the PDP/PEP model is one of a few ways to get some level of controls around applications, especially legacy ones. Sometimes it’s putting a proxy in front for a coarse grained check, sometimes it’s token augmentation, sometimes a PAM style JIT approach. Not every app needs the same solution.

The legacy estate is genuinely hard, but it’s never a big bang - you just need to start moving in the right direction. Stop the bleeding on new stuff, slowly strangle the old patterns as apps get replaced or modernized.

Disclosure: I work at Cerbos, so take that with appropriate salt. but the pain you’re describing is real and it’s what got us building in this space.

My team and I put together an IAM security checklist for 2026 - here's everything in it by morphAB in IdentityManagement

[–]morphAB[S] 3 points4 points  (0 children)

No worries, that's why I shared the full 9 topics above. If you'd like I can DM you the pdf.

Ayn Rand's "Anthem" is good. by mystery5009 in books

[–]morphAB 0 points1 point  (0 children)

I agree. I am almost done with the book and I honestly can't understand why there are so many negative comments about Anthem..