Streamlining Access: Identity and Access Management (IAM) Process

Streamlining Access: Identity and Access Management (IAM) Process

This post outlines my vision of company’s Identity and Access Management (IAM) process, covering application integration, access granting, and revocation. It’s intended for IT/Security staff managing IAM, as well as all stakeholders involved. For this document IAM system is selected as Entra ID but any other system like Okta can be considered

Intro

Goal is coverage of all applications and services, ensuring secure authentication and authorization using corporate credentials. This means integrating every application and service with our central Identity and Access Management (IAM) system.

Our source of truth for identities today is Entra ID (formerly Azure AD). All user accounts originate here. The “Identity Team” is a virtual competence team (potentially Security or IT) responsible for managing the IAM system.

1. Authentication and Authorization Flow

Here I will try to describe the high level flow. User accounts are ideally created in the HR system and synced to Entra ID. If no HR system exists, accounts are created directly in Entra ID.

  1. HR System (Optional): User account and ORG group assignment.
  2. Entra ID Sync: Account and group data synced from HR to Entra ID.
  3. RBAC Group Creation: RBAC groups created in Entra ID, populated with ORG groups.
  4. Application Integration:
    • Modern web apps: Direct integration with Entra ID (OpenID/OAuth/SAML).
    • Legacy LDAP systems: Integration via Azure Entra Domain Services.

2. Access Control: Ownership and Responsibility

We should distinguish between business applications (user/customer-facing) and critical enterprise systems (internal operations, e.g., firewalls).

  • Application/System Owner: Each application has an assigned owner responsible for application-specific questions.
  • Business Applications: The owner decides who gets access and what roles are assigned (and completes the Access Control Matrix). The owner is also responsible for notifying IT of user departures or role changes. Important: Not all applications support automatic deprovisioning. Manual access removal within the application may be required.
  • Critical Enterprise Applications: The Head of Security/CISO and Head of IT jointly decide on access levels.

Further I will list main principles taking into account the application difference that was describe above.

  • Each System/Application should have an Application/System Owner assigned to this application.

  • Application Owner is responsible for answering application specific questions.

  • For Business Applications, Application owner is the decision maker on who should have access to the application and what roles should be assigned. Application owner should fill out the Access Control Matrix Document.

  • In case a user leaves company or unit, application owner is responsible for informing the IT team so that access is revoked from Applications.

  • Important point to pay attention to here is that not all applications support auto provisioning and deprovisioning therefore sometimes removing user access in the Entra ID is not enough and User access should be removed inside application as well.

  • For Critical Enterprise Application Head of Security/CISO and Head of IT should decide to whom and what level of access should be granted.

3. Integration Process: A Phased Approach

We prioritize native (direct) Entra ID integration using web-based authentication protocols like OpenID, OAuth, and SAML for SSO. When necessary, we use Azure Managed Microsoft Entra Directory Services as an intermediary for LDAP-based applications.

Integration Methods:

  1. Native Integration – Native (Direct) integration to the Entra ID, using Web based authentication and authorization protocols such as OpenID, OAuth, SAML with SSO capability.  Entra ID>>Users
  2. LDAP Integration – Integration using Azure Managed intermediary Microsoft Entra Directory Services. In this case LDAP authentication is used. LDAP server syncs accounts from Entra ID and authentication is done using secure LDAP protocol. Entra ID >> Microsoft Entra Directory Services >> Users

Integration Steps

Following Diagram describe steps required to integrate applications to Identity Management System

  1. Information Gathering: The Identity Team gathers information from system owners (see “Mandatory Inputs” and “Questions” below).
  2. Testing: The Identity Team tests integration scenarios in a test environment.
  3. Group Creation: The Identity Team creates necessary groups in Entra ID (see “Groups” below).
  4. Integration: The Identity Team performs the integration in Entra ID. The IT team configures the application side.
  5. Handover (Optional): If the Security Team performed the integration, they hand it over to the IT team.

Mandatory Inputs for Integration

Followings are the mandatory information needed for the integration of applications to company IAM

  • Access Control Matrix – A document outlining roles, application permissions, and user/group mappings.
  • Entra ID Groups – Created based on the Access Control Matrix.
  • Application Authentication Details – Supported protocols and integration mechanisms.

Key Questions for System Owners

Following Questions can be asked to stakeholders to gather information

  • SaaS or self-hosted?
  • On-premises or cloud?
  • Internet access?
  • Supported authentication/authorization schemes (OAuth, OpenID, SAML, LDAP, RADIUS, Kerberos, Forms-based, etc.)?
  • SSO support and licensing?
  • Internal Role-Based Access Control (RBAC)?
  • Privileged access elevation needs?
  • Existing Access Control Matrix?

Integration Configuration: Shared Responsibility

Integration configuration is a shared responsibility. The Identity Team configures Entra ID, and the IT team configures the application, using parameters provided by the Identity Team. Modern web apps using SAML are integrated using vendor guides. LDAP integration parameters are application-specific and detailed in vendor documentation and internal guides.

4. Access Management

Group Management: ORG and RBAC Groups

To grant access to applications and manage users following two types of logical groups are necessary:

  • ORG Groups – Organizational groups according to the Organizational scheme and user’s job duties. For example. Group Names ORG-Security should include all Security team members. These groups ca further used to grant access to applications

  • RBAC Groups – Role Based Access Control groups. These are groups that are configured in applications that to grant access. ORG groups are included in RBAC groups to grant access.

For instance, we have RBAC Group called “metabase-admins”. This group is configured in Metabase application with administrative permissions. To grant Security team administrative level access to Metabase we need to Include ORG group called ORG-Security in to the RBAC group “metabase-admins”.

Onboarding

Onboarding is the process of granting access to users to the systems. In regular flow when a new user joins company or changes department onboarding of user accounts should be automatic process using ORG and RBAC groups described above.

In exceptional cases when a user needs access to systems that are not related to his regular job duties helpdesk request for access should be created by user or user’s manager and business justification should be provided. Application/System Owner should approve the request, then access should be granted by the Identity Team.

Offboarding

Offboarding is the process of removing access to systems when users leave, or job duties are changed. When User is leaving, System Owners and IT team should be informed to remove user’s access from systems. In ideal cases when there is proper App integration, access should be automatically removed from apps. In cases when automatic deprovisioning is not possible System/App owners are responsible for removing access in this kind of situations

Access Levels and Privileged Access Management (PAM)

We differentiate between:

  • Privileged Access: Administrative access to modify system settings and grant access to others.
  • Unprivileged Access: General access for regular use (e.g., querying a database).

We can use Entra ID PIM for just-in-time privileged access or other PAM/PIM tools

  • Unprivileged Access: Users are placed in unprivileged groups.
  • Privileged Access: Users needing temporary privileged access are eligible for privileged groups and can request elevation via Entra ID PIM.
  • Approval: Privileged access requests may require approval.
  • MFA: MFA is required for privileged access.
  • Group Separation: Production and non-production systems should have separate privileged groups.

(Diagram recommended here showing unprivileged and privileged group structure)

5. Access Audit

Regular audits (ideally twice per year) are conducted by the Infra/IT team, with input from application/system owners, to identify alumni users and overly permissive access. Audit reports are retained for compliance.

6. Actionable Directives: Who Does What

Information Gathering (Identity Team):

  1. Collect the following information for each application:
    • Integration Method (SSO or LDAP)
    • Completed Access Control Matrix
    • Vendor documentation (if available)

Group Creation (Identity Team):

  1. Create groups in Entra ID according to the Access Control Matrix and naming conventions (see “Group Naming Convention” document).

Integration Configuration:

  1. Entra ID (Identity Team): Configure integration in Entra ID.
  2. Application (IT/Infra Team): Configure application side, using parameters provided by the Identity Team. Consult the Identity Team for assistance if needed.

Production Deployment (IT Team): Deploy configurations to production systems after successful testing.

Comments are closed.