Identity Providers and Organizational Hierarchy
Why the Identity Provider is Fundamental​
Apono does not manage users and passwords directly. It relies on an Identity Provider (IdP) as the source of truth to know:
- Who the users are in the organization.
- Which groups each user belongs to (e.g., backend-team, infra-team, security-team).
- Who is the manager of each person — essential information for approval flows.
Without this integration, Apono cannot automatically determine who should approve an access request when the rule is "direct manager approval". It is the Identity Provider that provides this hierarchy.
If the organization does not yet have the manager hierarchy configured in the Identity Provider, Apono can still be used normally. A common adoption strategy is to start with a single team (such as the security or infrastructure team) approving all access requests. Over time, as the organization matures and configures the hierarchy in the Identity Provider, approvals can be gradually delegated to direct managers and team leaders. This approach allows adopting Apono quickly without depending on a complete organizational structure from day one.
Supported Providers​
Apono supports the main identity providers on the market:
| Provider | Protocols | Synchronization |
|---|---|---|
| Microsoft Entra ID (Azure AD) | SAML, OIDC, SCIM | Users, groups, and manager hierarchy |
| Okta | SAML, OIDC, SCIM | Users, groups, and manager hierarchy |
| Google Workspace | OIDC, SCIM | Users and groups |
| OneLogin | SAML, OIDC | Users and groups |
Synchronization happens continuously — when a user is added, removed, or moved between groups in the Identity Provider, Apono automatically reflects these changes.
Configuring the Manager Hierarchy in Entra ID​
Microsoft Entra ID (formerly Azure AD) is one of the most widely used providers in corporate environments. For Apono to automatically identify who each person's manager is, the Manager field needs to be filled in each user's profile.
How the Manager Field Works​
In Entra ID, each user has an attribute called Manager that points to another user — their direct manager. This relationship creates a hierarchical chain that Apono queries when an Access Flow requires "direct manager approval".
In this example, if Pedro Oliveira requests access to a resource with direct manager approval, Apono automatically forwards the request to Ana Costa (his manager in Entra ID).
Configuring the Manager via Azure Portal​
To set a user's manager in Entra ID:
- Access the Microsoft Entra admin center (entra.microsoft.com).
- Navigate to Identity → Users → All users.
- Select the user you want to configure.
- In the Properties section, click Edit properties.
- In the Job information tab, locate the Manager field.
- Click Change manager and select the correct manager.
- Save the changes.
Configuring the Manager via Microsoft Graph API​
For organizations with many users, configuring the manager manually through the portal is not feasible. The Microsoft Graph API allows automating this configuration:
# Set a user's manager via Graph API
# Replace {user-id} with the user ID
# Replace {manager-id} with the manager ID
curl -X PUT \
"https://graph.microsoft.com/v1.0/users/{user-id}/manager/\$ref" \
-H "Authorization: Bearer {access-token}" \
-H "Content-Type: application/json" \
-d '{
"@odata.id": "https://graph.microsoft.com/v1.0/users/{manager-id}"
}'
# Set the manager via PowerShell with Microsoft Graph module
# Install: Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "User.ReadWrite.All"
# Set the user's manager
$managerRef = @{
"@odata.id" = "https://graph.microsoft.com/v1.0/users/{manager-id}"
}
Set-MgUserManagerByRef -UserId "{user-id}" -BodyParameter $managerRef
Configuring Hierarchy in Okta​
In Okta, the manager hierarchy works similarly:
- Access the Okta Admin Console.
- Navigate to Directory → People.
- Select the user.
- In the Profile section, edit the Manager or managerId field.
- Enter the manager's ID or email.
Okta also allows configuring the Manager field automatically via HR system imports like Workday, BambooHR, or SAP SuccessFactors — which ensures the hierarchy is always up to date.
How Apono Uses the Hierarchy​
When Apono connects to the Identity Provider, it synchronizes not only users and groups but also the management relationship between them. Since the Manager field creates a hierarchical chain (Pedro → Ana → João → Maria), Apono can navigate through this chain and use any level of it in approval flows.
This allows configuring Access Flows with rules like:
- Direct manager approval: Apono automatically identifies who the requester's manager is and sends the approval notification.
- Manager's manager approval: For more sensitive access, Apono goes up one level in the hierarchical chain and sends the approval to the manager's manager. This is useful when the access impacts areas beyond the direct leader's scope.
- Multi-level hierarchical approval: It's possible to combine both — first the direct manager approves, then the manager's manager approves. Both need to approve for access to be granted.
- Group-based approval: Apono knows which groups the user belongs to and can direct approval to those responsible for that group.
Example: Hierarchical Escalation​
Considering the hierarchy below:
Different flows can be configured depending on sensitivity:
| Access Type | Approver | Hierarchical Level |
|---|---|---|
| Read-only in staging | Ana Costa (direct manager) | 1 level up |
| Write in production | Ana Costa + João Santos | 1 and 2 levels up |
| Admin in production | Ana Costa + João Santos + Security Team | 1 and 2 levels + fixed group |
The diagram below illustrates an approval flow with two hierarchical levels — where both the direct manager and the manager's manager need to approve:
This ability to navigate the hierarchical chain is what makes the Identity Provider integration so important — without the Manager field correctly filled, Apono cannot automatically resolve who the manager's manager is.
Best Practices​
- Keep the hierarchy updated: Team changes, promotions, and departures should be immediately reflected in the Identity Provider. If the Manager field is outdated, approvals go to the wrong person.
- Automate via HR systems: Whenever possible, integrate the Identity Provider with the HR system (Workday, BambooHR, SAP) so that organizational changes are synchronized automatically.
- Define a fallback: Configure a default approver for cases where the direct manager is not defined or is unavailable. Without this, requests can get stuck waiting for approval.
- Validate the configuration: Before putting Apono into production, verify that all users have the Manager field correctly filled. Users without a defined manager cannot use flows that depend on this information.
- Use groups for segmentation: In addition to the manager hierarchy, organize users into groups that reflect teams and responsibilities. This facilitates creating team-specific Access Flows.