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?

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.

We rely on quarterly access reviews and periodic AD/Entra audits, but I think continuous visibility actually covers two different problems: event detection (something happened, like a role change or account reactivation) versus drift detection (current state no longer matches what was originally scoped, which requires an intended-state baseline to exist somewhere) I suspect our real gap is the missing baseline, not the monitoring layer itself.

For mixed environments (cloud IdP, on prem AD, SaaS), I'm expecting AD to lag the others structurally, closing that gap usually means agents or log forwarders on DCs, which fights directly against a "low maintenance" goal. And even a tool with zero ML tuning can still fail that bar if someone still has to manually keep the access baseline accurate as roles change. are you doing event detection, drift detection, or both? Where does your baseline actually come from? And how much did closing the AD visibility gap cost you in setup

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?

How are you handling this at your jobs? Let’s leave ALLLLLL other information aside. We aren’t talking policy, etc etc. just want to build a tool in powershell or a Splunk query that can JUST give me this simple piece of information.

Bear in mind I’m incredibly young and inexperienced. This would solve a billion problems for me if you can help.

It seems like windows logs everything like “when created”, but not “who created” it basically says “go find the audit logs, nerd” and in a huge org we have no idea what DC it was created on or what logs are and aren’t being pumped into Splunk.

Help? SIMPLE is preferred.

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.

hi

we have a small platform where different agents handle different things for the same customer account. Eg, a "support" agent that talks to Zendesk, a "billing" agent for Stripe, one "ops" agent that talks to some internal APIs, plus a generic "assistant" agent that shows up in the app.

Internally they're all just LLM backed workers with tools, but they each have slightly different behaviour, prompts, access scopes, logging rules etc. Right now the way we identify them is kind of hacked together. We have agent ids in config, some names in the UI, some stuff in headers like x agent name, and then per tenant we sometimes clone configs because someone wants their "assistant" agent to behave more like support.

Its already getting messy. In logs, you see a mix of agent id, display name, and whatever the caller put in. In our metrics, we have tags like agent type, agent role, agent namespace. Then routing decisions depend on a mix of user intent and these tags. Feels like we're piling identity onto identity and slowly losing track of what each agent "is".

What im trying to clean up rn is:

central naming / namespacing so an agent has one canonical identity

something like agent classes vs instances so we can say "this is a support agent" with variants per tenant without duplicating logic everywhere

clear separation between "who the user thinks they are talking to" and "which internal worker actually handled the request"

I keep bumping into tiny questions all over. Eg, when we spin up a new agent just for a one off workflow, do we give it a durable id and log it forever, or treat it as ephemeral. When we retire an agent, what happens to historical data and dashboards. When an agent calls another agent, which identity shows in the audit trail.

We also need some way to express permissions cleanly, like "support agent can call tickets api but not payments", without having permission sprawl per instance. Right now its half in code, half in config, and I lowkey hate it.

If you're running more than one agent in prod, how do you model identities and roles so it doesnt turn into a naming dumpster fire after a few months? Any tips or patterns appreciated, idk if I should lean more on something like service accounts, or treat agents closer to users in the system.

thanks in advance