Identity & Least-Privilege Modernization

Identity Security · IAM · Zero Trust · Okta · Cloud Access

Building a More Scalable Identity and Access Model

Identity is one of the most important security boundaries in a modern environment.

As organizations grow, access often becomes harder to manage. Users accumulate permissions over time, applications are integrated differently, privileged roles remain assigned longer than necessary, and access decisions become increasingly difficult to review.

I worked on improving identity and access management by moving toward a more centralized, group-driven, and least-privilege model across cloud and SaaS environments.

The goal was to make access:

Consistent

Auditable

Scalable

Least-privileged

Easier to manage over time

The Problem

Identity environments often become fragmented because access is added incrementally.

A user needs access to an application.

An administrator grants it directly.

A developer needs elevated cloud permissions.

A role is assigned manually.

A team expands.

Another set of exceptions is created.

Over time, this creates several common problems:

• Direct user assignments

• Inconsistent role definitions

• Persistent privileged access

• Difficult offboarding

• Hard-to-audit permissions

• Application-specific access models

• Manual provisioning

• Role drift

• Excessive access after job changes

The challenge is not simply authenticating users.

It is understanding:

Who should have access to what, why, and for how long?

My Approach

I focused on making identity more centralized and policy-driven.

The broader model was based around:

Centralized Authentication

↓

Group-Based Authorization

↓

Role-Based Access

↓

Least Privilege

↓

Continuous Review

This helped move access decisions away from one-off user assignments toward reusable access patterns.

Okta as the Identity Layer

Okta was used as a central identity provider for multiple applications and services.

This included work around:

• Single Sign-On

• SAML integrations

• OIDC/OAuth integrations

• SCIM provisioning

• Group-based application assignment

• MFA

• Lifecycle management

• Access reviews

Centralizing authentication reduced the need for separate credentials across multiple applications.

It also improved visibility into who had access and how authentication was being enforced.

SAML, OIDC, and SCIM

Different applications support different identity standards.

Understanding those differences is important when designing access.

SAML

SAML was commonly used for enterprise SSO.

It allowed authentication to be delegated to the identity provider rather than maintaining separate application passwords.

OIDC / OAuth

OIDC and OAuth provided a more modern authentication and authorization model for applications and APIs.

These integrations often required careful review of:

• Redirect URIs

• Scopes

• Client permissions

• Token lifetime

• Application trust

SCIM

SCIM helped automate user lifecycle management.

Rather than manually creating and removing accounts inside every SaaS platform, provisioning could be tied more closely to the central identity system.

This reduces orphaned accounts and improves offboarding.

Group-Based Access

One of the most important improvements was moving away from direct individual assignments.

Instead, access could be tied to groups.

For example:

User

↓

Identity Group

↓

Application Role

↓

Authorized Resource

This makes permissions easier to understand and manage.

Instead of asking:

Why does this person have access?

you can ask:

What group gives them access, and why are they in that group?

That is a much more scalable question.

Structured Group Naming

A structured naming model can make identity significantly easier to operate.

For example, group names can encode:

• Scope

• Environment

• Application

• Role

A structured pattern makes permissions easier to recognize during:

• Access reviews

• Troubleshooting

• Audits

• Provisioning

• Offboarding

The exact naming convention matters less than consistency.

AWS Identity Center

Cloud access was also an important part of the identity model.

AWS Identity Center can provide centralized access to AWS accounts and roles.

Instead of relying on long-lived IAM users or individually managed credentials, users can access AWS through centrally managed identities and role assignments.

This supports:

• SSO

• Centralized access management

• Role-based permissions

• Short-lived credentials

• Easier offboarding

• Reduced credential sprawl

Least Privilege

Least privilege sounds simple:

Give users only the access they need.

In practice, it is much harder.

Access needs change.

Teams move.

Projects end.

Temporary privileges become permanent.

The goal should therefore be:

Minimum necessary access, reviewed continuously.

Least privilege was considered across:

• AWS

• SaaS applications

• Administrative roles

• Development tooling

• Security platforms

• Endpoint administration

Persistent Privilege

One of the highest-risk identity patterns is persistent administrative access.

If someone only needs elevated access occasionally, permanent admin rights increase risk without providing proportional value.

Better patterns include:

• Temporary elevation

• Separate privileged roles

• Just-in-time access

• Approval workflows

• Break-glass accounts

• Strong MFA

• Session logging

Even when a full PAM platform is not available, the principle remains useful:

Elevated access should be exceptional, not normal.

Zero Trust

The identity design also aligned with Zero Trust principles.

Zero Trust does not mean “trust nobody.”

It means access should not be granted solely because someone is:

• On the corporate network

• Using a company laptop

• Inside the cloud environment

• Already authenticated

Instead, access decisions should consider:

• Identity

• Authentication strength

• Device posture

• Role

• Resource sensitivity

• Context

• Ongoing authorization

Defense in Depth

Identity controls are stronger when combined with other protections.

For example:

SSO

MFA

Managed endpoint

Least privilege

Logging

Access review

is stronger than any single control by itself.

This is why identity security should not be treated as a standalone system.

It intersects with endpoint security, cloud security, logging, and incident response.

Joiner, Mover, Leaver Lifecycle

Identity security is heavily influenced by employee lifecycle events.

Joiners

New employees should receive standardized access based on role rather than ad hoc assignments.

Movers

Role changes are particularly dangerous because users may retain old access while gaining new permissions.

Leavers

Offboarding should remove access quickly and consistently.

SCIM and centralized identity help reduce manual steps during these events.

Human and Non-Human Identities

Identity is no longer only about employees.

Modern environments also contain:

• Service accounts

• API keys

• CI/CD identities

• Cloud roles

• Kubernetes service accounts

• Machine identities

• AI agents

These identities can be just as privileged as human users.

In some cases, they are more privileged.

That means identity programs increasingly need to consider:

Humans

and

Machines

using the same principles:

• Least privilege

• Clear ownership

• Short-lived credentials

• Rotation

• Logging

• Review

Practical Tips & Tricks

1. Prefer groups over direct assignments

Direct assignments are harder to review and easier to forget.

Use:

User → Group → Role

whenever practical.

2. Make group names understandable

A group called:

admins-2

does not tell you much.

A structured name can indicate:

• Application

• Environment

• Role

• Scope

That makes reviews much easier.

3. Avoid long-lived cloud credentials

Where possible, use:

• SSO

• Role assumption

• Temporary sessions

• Workload identity

Long-lived access keys increase both operational burden and security risk.

4. Separate privileged access

Administrative access should be clearly distinguishable from normal user access.

This improves:

• Logging

• Review

• Incident investigation

• Risk awareness

5. Review movers carefully

Employees who change teams often accumulate permissions.

A role change should trigger:

Add new access

and

Remove old access

not just the first half.

6. SCIM reduces offboarding risk

Automated deprovisioning is one of the most valuable benefits of SCIM.

It reduces reliance on someone remembering to manually disable every SaaS account.

7. Authentication is not authorization

A user successfully logging in does not mean they should have access to every resource.

Keep these concepts separate:

Authentication: Who are you?

Authorization: What are you allowed to do?

8. Track service accounts like employees

Every non-human identity should have:

• An owner

• A purpose

• Defined permissions

• Credential lifecycle

• Logging

If nobody owns a service account, it is already a risk.

9. Reduce shared accounts

Shared credentials make attribution difficult.

Whenever possible, actions should map back to a specific identity.

10. Design access with offboarding in mind

A good identity model should answer:

If this person left today, could we confidently remove their access?

If the answer is unclear, the model probably needs improvement.

Access Review Strategy

Periodic access reviews should focus on questions such as:

• Does this user still need the role?

• Is the role broader than necessary?

• Are privileged users still active?

• Are dormant accounts present?

• Are service accounts still needed?

• Are direct assignments bypassing the intended model?

Access reviews are more useful when the underlying identity structure is already clean.

Logging and Investigation

Identity telemetry is also critical during incident response.

Useful sources can include:

• Okta logs

• AWS CloudTrail

• AWS Identity Center events

• SaaS audit logs

• Endpoint telemetry

• Authentication logs

This helps answer questions such as:

• Who authenticated?

• From where?

• What role was assumed?

• What resource was accessed?

• Was MFA used?

• Was access expected?

Outcome

The work helped create a more structured identity model based on centralized authentication, group-based authorization, and least-privilege access.

It improved:

• SSO consistency

• Access visibility

• Role organization

• Provisioning

• Offboarding

• Cloud access management

• Least-privilege enforcement

• Identity auditability

More importantly, it moved identity away from ad hoc access assignment and toward a more scalable security architecture.

Technologies

Okta · SAML 2.0 · OIDC · OAuth 2.0 · SCIM · AWS IAM · AWS Identity Center · RBAC · MFA · SaaS Security · Cloud Identity

What This Demonstrates

This project demonstrates experience in:

• Identity and access management

• Zero Trust

• Least privilege

• Okta

• SSO

• SAML

• OIDC/OAuth

• SCIM

• AWS IAM

• Cloud identity

• RBAC

• SaaS security

• Access governance

Key Takeaway

Identity scales best when access is attached to roles and groups—not individual people—and when privilege is treated as temporary rather than permanent.