Most places treat identity and access management like paperwork. Someone needs access, a ticket gets filed, a permission gets granted, and everybody moves on. It’s the path of least resistance, but it’s also how you end up with an environment where nobody really knows who (or what) has access to what, and auditing anything becomes an archaeology project.
Really, we should think about IAM as part of how a system is designed, not something that happens after the design is done. Who can touch what, how services authenticate to each other, what happens when someone leaves, these are all load-bearing decisions, not afterthoughts. Of course, many of us actually inherit systems that are pre-designed, which actually does seem like an archeaology project whether we want it to or not. I’ve taught courses on Windows Server and Active Directory, and I try to give my students realistic (read messy) environments to inherit, since they’re not going to get a clean forest when they walk into a Windows shop that’s been using AD for 25 years.
The thing I keep coming back to is the difference between a person and a role. People leave, get promoted, take on three different jobs over five years. Roles are tied to functions, and functions usually outlast the individuals doing them. If your permissions model is built around people, it accumulates debt fast and becomes very hard to untangle later.
I see this in Active Directory constantly. AD has a reputation for always being kind of a mess, and in my experience that’s usually because it was built around individuals and exceptions rather than structure. Group membership sprawl, stale accounts, nested groups nobody can explain, all of it traces back to the same root. The directory stopped reflecting how the organization actually works and started reflecting how it worked four years ago. Cleaning that up is unglamorous work, but it’s where a lot of real operational improvement comes from. When AD is clean, authentication is clean, delegation is clean, and onboarding stops being so tedious.
Least privilege is the principle everyone cites and fewer people actually enforce. In practice it means being willing to ask what a service or account actually needs and giving it exactly that. The “just in case” permissions are where you get hurt, and they’re usually where you get confused six months later when something breaks.
I work in a library, and this stuff matters there as much as anywhere. Library systems have discovery tools, authentication layers, resource sharing platforms, integrations, automation. The language is specific to the domain but the underlying problems are the same ones any systems engineer deals with. Role-based access, service accounts, scoped permissions, clean boundaries between human and machine workflows.
I’ll probably write more about identity and access in the future because it’s one of those things that requires constant strategy and attention. Getting it right is one of the better things you can do for an environment’s long-term health. Getting it wrong compounds quietly for years.