Skip to content

Microsoft Entra ID

Stable Connected tier

Microsoft Entra ID is the identity backbone of the Demiton platform. Beyond authentication (handled natively via OIDC), the Entra ID adapter enables workflows to read directory data, manage group membership, and write identity attributes as part of workforce lifecycle automation.

Authentication: OAuth 2.0 via service principal (Microsoft Graph)
System type: ENTRA_ID
Protocol: Microsoft Graph API v1
API reference: Microsoft Graph - Identity


Supported resources

ResourceFETCHPUSHLOOKUPEXECUTELicense
usersFree
groupsFree
group_membersFree
group_membershipFree
user_clearanceFree
security_groupsFree
directory_role_assignmentsFree
service_principalsFree
signin_logsP1
mfa_registrationP1
risky_usersP2

PUSH on group_membership adds or removes members in batch. LOOKUP on user_clearance resolves a user’s transitive group memberships. EXECUTE on security_groups supports create_group, add_member, and remove_member commands.

signin_logs, mfa_registration, and risky_users are used for security audit workflows. Resources marked P1/P2 return an empty dataset (not an error) on tenants without the required Entra ID licence - the audit report will note the gap rather than failing.


Integration model

Used in two contexts:

Access resolution - Demiton reads Entra user attributes and group memberships at query time to determine what data each user is authorised to see. This happens automatically for every platform interaction.

Workforce lifecycle workflows - When a new hire is created in KeyPay, Demiton can provision their Entra account and write HR-owned attributes (department, job title, city, employment type, manager, employee ID). On termination, Demiton sets accountEnabled = false, revoking platform access immediately.


Connection setup

Required values:

  • Tenant ID
  • Client ID - Entra app registration
  • Client Secret

The Entra ID connector is typically configured during platform onboarding by your Customer Success Manager.


Required Graph permissions

Grant these on the app registration used by the Demiton service principal. All permissions are application type (not delegated).

PermissionPurposeMinimum licence
User.Read.AllDirectory user readsFree
Group.Read.AllDirectory group readsFree
RoleManagement.Read.DirectoryDirectory role assignmentsFree
Application.Read.AllService principals & enterprise appsFree
GroupMember.ReadWrite.AllGroup membership write-back workflowsFree
User.ReadWrite.AllHR attribute write-back workflowsFree
AuditLog.Read.AllSign-in logs and MFA registration reportsP1
UserAuthenticationMethod.Read.AllMFA registration details per userP1
IdentityRiskyUser.Read.AllIdentity Protection risky user dataP2

Minimum for read-only directory access: User.Read.All, Group.Read.All

For security audit workflows: additionally RoleManagement.Read.Directory, Application.Read.All, and the P1/P2 permissions above depending on your licence

For workforce lifecycle write-back: additionally User.ReadWrite.All, GroupMember.ReadWrite.All

To grant consent: open Entra admin centre → App registrations → [your app] → API permissions → Add permission → Microsoft Graph → Application permissions, add each permission, then Grant admin consent.


Security

Access type: Read and scoped write

Demiton reads identity attributes and group memberships to enforce access controls. Writes are strictly scoped: Demiton writes only six HR-owned attributes (department, jobTitle, city, employeeType, manager, employeeId) and the accountEnabled flag. These writes occur only through governed workforce lifecycle workflows.

What Demiton never writes: Application role assignments, conditional access policies, or any other Entra surface outside of HR attributes and explicitly configured group-management workflows.


Next steps