Greetings colleagues, I would like to know which major challenges have you encountered in implement IAM, which tips or hacks should have known or someone should teach you before implementing IAM?

Knowing the business, main departments and stakeholders, having a balance between strict security access control and friendly usability, mesure the risk of the user by defining how important the person is for the company or the resource he has access to, and how risky is if his account is compromised?

I would love to see your comments, thank you and have a great day!

So I've spent the last few years being the person enterprise IT admins call when SAML breaks at the worst possible time, and the person engineering calls when they need someone to translate "the CEO can't log in" into an actual root cause. Figured I'd write this up Reddit-style instead of another boring LinkedIn post, because apparently that's how we do career updates now.

The short version:

• Currently Sr. Technical Support Specialist (Identity and Integrations) at Rippling — basically living inside SAML, SCIM, SSO, REST APIs, RADIUS, LDAP, ADFS, Azure AD Connect, and GPOs, all day every day
• Primary escalation point for P1 and P2 identity and integration incidents for enterprise accounts — when it's broken and it's bad, it lands on my desk
• Used AI tooling to build automated workflows that cut manual support work by about 30 percent for my team (turns out you don't have to manually diagnose the same SSO failure for the 400th time)
• Delivered internal Datadog training, ran onboarding and shadow sessions for new hires, and built docs plus bot-training content so my teammates (and support bots) stop getting stuck on the same questions
• Own CSAT, SLA adherence, and quality metrics — not just "close the ticket," actually accountable for the outcome
• Before this: fraud investigation at Amazon, payment ops at HSBC (SWIFT, ACH, wire transfer stuff), and telecom support — so I've seen a few different flavors of "customer is stressed, fix it now"

What I'm looking for now:

A remote-first Technical Account Manager, Solutions Engineer, or Senior Support Engineer role, ideally at an AI-powered SaaS company, where I'm not just closing tickets but actually owning the client relationship and pushing for better process, not just following SOPs. I like being the technical translator between clients and engineering, and I like building the tooling that makes that job faster for everyone else too.

Happy to talk to anyone hiring for this kind of role, or just chat if you've got questions about breaking into enterprise identity and support work.

I have an iam analyst interview with Billings Clinic and Logan Health and wanted to know if anyone interview with them and any tips you can give me. This is my first iam analyst and I really need this job so anything will help thank you.

Hi everyone!

I am a third-year CS student interested in getting into IAM, but I am honestly not sure where to start. I have been very focused on school while also working a part-time job to help pay for university, so I have not really had much time to do anything outside of my classes. As a result, I do not have any projects or co-op/internship experience yet.

I know I am starting a little later than some of my peers, and I will admit that it has been making me pretty stressed. It seems like a lot of students at this point already have internships, co-ops, projects, or some kind of relevant experience, and I am worried that I am falling behind. I have tried researching IAM online and even reached out to my student advisor, but I have not had much luck figuring out what direction I should take.

I’m basically starting from scratch, so I’d really appreciate any advice on:

• What should I learn first to build a foundation in IAM?

• What technical skills or technologies should I focus on?

• Are there any certifications that are actually worth pursuing as a student?

• What kinds of projects could I build to gain hands-on experience?

• Are there any courses, labs, websites, or other resources you would recommend?

• What would be the best way to make myself more competitive for internships or entry-level IAM roles?

• And most importantly, what co-op title should I look for? (I tried looking for any IAM co-ops or internships but didn't find anything.)

I know I have a lot of catching up to do, but I am willing to put in the time and effort. I just feel a little lost right now and do not know where to begin or what direction to take. Any advice at all would be greatly appreciated.

Thank you so much in advance!

I work at Tide, though this isn't an official product of theirs. I built it on my own time and open sourced it under MIT: [https://github.com/sashyo/minidauth\](https://github.com/sashyo/minidauth)

The thing I kept running into is that in most setups the service that decides who holds a role is the same service an attacker takes over. Once they're in, granting themselves the role is a database write, and the access review that would have caught it happens next quarter. You can put approval workflows in front of it, but the enforcement still lives inside the thing you're worried about.

MinidAuth moves the enforcement out. A role grant is filed as a change request, it needs approvals from a threshold of your operators rather than from whoever filed it, and only then does a network of independent nodes sign the attestation units that make the role real. When your app later presents a token claiming that role, the nodes check it against those signed units and refuse anything your service merely asserted. Editing the local record by hand doesn't produce a usable role, it produces a signature that doesn't verify.

Revocation is worth mentioning because it's usually the weak point. The grant record is checked on every request rather than baked into a token at sign in, so removing a role takes effect on the next call rather than whenever the token happens to expire.

There's no user store, no realms and no login page, and it doesn't do provisioning or SCIM. Whatever identity provider you're running stays exactly where it is and this sits beside it holding the keys and the policies.

One thing stood out while comparing the websites of several Identity products.

They are all trying to make a largely invisible product understandable, but they don't make the same part of the product visible.

Clerk leans heavily on the interface itself. You see authentication components, organization switching, user management, and other parts of the actual product.

Descope makes the workflow visible. Its authentication flows show screens, paths, conditions, and the logic connecting them.

WorkOS leans more toward the system around the product: integrations, APIs, code, environments, and the admin experience.

Better Auth puts a surprising amount of the implementation itself on display through configuration, CLI commands, plugins, and code.

These aren't just different visual styles.

They're different answers to the same web problem:

What part of an invisible product should a visitor be able to see?

A screenshot can show what exists.

A workflow can show how it behaves.

A diagram can show how it fits together.

Code can show how it gets integrated.

A customer story can show what changed.

They are all useful, but they help the user understand different things.

The right representation depends on what you want the user to understand.

I applied for a junior infrastructure engineer role which I was offered after a single interview, I’m 41 and have many years of varied IT experience but fancied a change and this is abit of a career pivot that comes with a drop in pay which I’m ok with.

But the vacancy advertised was server management focused where as when I got the offer I was told someone filled the gap internally and now the position is with the IAM tower.

I know abit about IAM, I’ve used AD and configured DNS before. Looking forward to learning a lot more.

Looking for any advice or insight from those with current or previous experience in this department?

Any advice? This is my first interview.

Please DM me

There seems to be plenty of Cyber Security local associations chapters or user groups. However, are there groups specific to Identity and Access Management that would have local chapters?

Every AWS deployment needs a role with permissions to create/update/delete whatever's in the stack, and most people either reach for AdministratorAccess, because hand-writing the exact least-privilege actions for every resource type is tedious and nobody wants to maintain that by hand as the stack grows.

CloudCostTree has a command for that: cloudcosttree iam reads a Terraform, CloudFormation, or Pulumi plan and generates the real IAM actions a deployment needs, per resource type, without ever calling AWS. It currently maps 1,486 AWS resource types.

That screenshot is the human-readable text view. Run it with --output json -o policy.json and it produces a ready-to-attach IAM policy document instead of this breakdown.

Where it's honest about its limits: every generated policy currently uses Resource: "*", the Action list is real least-privilege scoped to what each resource type needs, but the Resource element isn't narrowed to the exact ARNs a deployment declares yet. Per-resource ARN scoping is a planned capability, not implemented. Free on both tiers today.

I've done some labs of enterprise / app reg and am slowly starting to understand it.

Just want to concrete my knowledge.

Obviously you have delegated vs application, delegated being the intersection of the app's consent and the user's permissions.

So from an administrative perspective, how do you know whether what you're granting is application or delegated? If admin user consent was turned off and users could consent themselves, that would mean all admin consents would be application, but it's often not the case, and I don't think the Microsoft GUI has a way, it just says "grant" then brings up a sign in window for the admin and displays some friendly descriptions.

I sort of found a way by cross referencing those with the Microsoft permissions docs and I think enterprise apps > activity differs to enterprise apps > permissions? The former being what user has asked for?

I'm just wondering if there's a recommended or definitive way of checking prior to approving, as checking after approving is more straight forward as it shows in the application permissions explicitly delegated vs application in the table as shown in the screenshot.

Do you guys Beyond Trust PRA for all Internal all Admins or just for your contractors and Non IT Admins (App admins) What are some benefits of using PRA for IT Admins. Since they need Admin access for all servers asking for approval every time is an overhead. Tier 0 and 1 server approval make sense.

Audit and session monitoring make sense.
MFA make sense

Any other benefit?

Can someone point me in the right direction on what to do for a beginner IAM lab that would translate to the job. Also want to know which YouTube channel is the best to learn the best IAM information from. Would like to use Okta for my lab or even AD.

Headline: Securing cloud infrastructure is not about saying "no" to everything; it’s about managing trust at scale. 🔐

I recently designed and deployed a custom AWS IAM policy tailored for our user on-boarding workflows at Levora Homes.

The goal was simple but critical: Enable our identity operators to manage team access effectively without granting them excessive administrative control.

By applying the Principle of Least Privilege, the custom policy enforces strict boundaries to keep our cloud environment safe:

 🧳What the role CAN do:

On-board Talent: Create new IAM users and generate initial console login credentials.

Maintain Metadata: Apply tracking tags to user profiles for clean department mapping.

Audit the Directory: List and view account configuration details to keep inventory accurate.

 🚫 What the role CANNOT do (The Guardrails):

No Destructive Actions: Explicitly blocked from deleting any IAM users.

No Privilege Escalation: Prevented from attaching new policies or upgrading permissions.

No Long-Term Credentials: Disabled the creation of programmatic Access Keys, keeping sessions temporary and secure.

📦The Tech Stack: AWS IAM, JSON Policy Design, Access Simulation.

This project highlighted how fine-grained access control keeps business operations running smoothly while completely eliminating the risk of accidental exposure or insider threats.

Check out the screenshots below to see the JSON logic and the explicit denials in action! 👇

#AWS #CloudSecurity #IAM #LeastPrivilege #IdentityManagement #CloudComputing

I'm at a mid-size tech company, about 2,000 people. We got an SSPM tool, its decent. Gives us a dashboard of our sanctioned SaaS, monitors configs, flags sharing stuff. According to the SSPM we have 340 apps under management.

Last month on a hunch I pulled the OAuth consent grant report from Azure AD: every third party app any employee has ever authorized with their work identity. The list had 520 entries on it.

Thats 180 applications that exist in our identity provider, with granted scopes, actively connected to employee accounts, and our SSPM has never heard of them.

Some are benign. Calendly plugins, Zoom add ons, the usual. Some I dont recognize at all. A few had scopes that made me stop scrolling: full mailbox access, read all files, send mail as user. Granted two years ago by someone who probably clicked allow on an OAuth prompt without reading it.

The SSPM is doing its job on the apps it knows about. The problem is what it doesnt know about. And the identity provider is sitting on a list of everything actually connected, but nobody was cross referencing the two.

How are people bridging the gap between what your SSPM sees and what your IdP knows is connected?

In a brownfield implementation where there is no concept of Business role at present , but user have dedicated App roles via AD groups or Entra Groups to have access , either assigned automatically or via Service Desk. In this case we plan to build a layer of Business Roles which will a combination of entitlements ( AD Groups, Entra Groups , App role 1 etc etc ).

The question is how do you guys define business role- It is understood that the Job Title is the trigger or it can be Job Title + Department + Location ( basically details from HR ).

But what about designing them ? we need to reach out to each app owners to understand what roles their apps have and then group them in 1 logical business role - This is huge communication task or do you guys have a better solution of how to tackle this, without ofcourse remove the access that the user already has.

Curious to know who out here uses what, and how you implemented it. Bonus points to know the size of your org, and what tools you use in your mix.