Hoe geef je toegang tot applicaties via groepen in Entra ID?

Applicatietoegang via groepen regel je in Entra ID door de app als enterprise application te registreren, onder Properties de optie "Assignment required" op Yes te zetten, en vervolgens onder Users and groups je toegangsgroep toe te wijzen, eventueel gekoppeld aan een app role. Vanaf dat moment bepaalt het groepslidmaatschap wie de app ziet en kan gebruiken. De valkuil: alleen directe leden tellen; een geneste groep binnen je toegangsgroep krijgt níéts.

Wie dit goed inricht, heeft per applicatie één plek waar toegang geregeld is. Wie het overslaat, heeft apps die voor de hele organisatie openstaan zonder dat iemand dat ooit zo besloten heeft.

Quick facts

Hoe het werkt en waar het misgaat

Elke applicatie die via Entra authenticeert, leeft in je tenant als enterprise application. Twee instellingen bepalen samen het toegangsmodel. De eerste is Assignment required onder Properties. Staat die op No (de standaard), dan kan iedere gebruiker in je tenant die de URL kent zich aanmelden; de toewijzingen onder Users and groups zijn dan alleen cosmetisch voor de app launcher. Staat hij op Yes, dan is toewijzing een echte toegangspoort. Voor elke applicatie met bedrijfsdata wil je Yes, en het loont om je bestaande apps hier vandaag nog op na te lopen.

De tweede is de toewijzing zelf. Wijs nooit personen toe maar altijd groepen, ook als het er nu maar drie zijn. De groep is je beheerpunt: toegang intrekken is een lidmaatschap verwijderen, en de vraag "wie kan bij deze app" is één ledenlijst.

App roles: rechten binnen de app

Ondersteunt de applicatie app roles (veel gallery apps en alle zelfgebouwde apps met een rollenmodel), dan koppel je per groep een rol: APP-Exact-Gebruiker krijgt de rol User, APP-Exact-Beheer de rol Admin. De rol reist mee in het token en de applicatie richt er zijn autorisatie op in. Zo verhuist ook het rechtenbeheer bínnen de app naar je groepsmodel.

De nestingval, opnieuw

Net als bij licenties geldt bij app assignment: alleen directe leden. De constructie waarbij je een afdelingsgroep nest in een app-toegangsgroep ziet er logisch uit en doet niets. Dit is geen randgeval maar de meest gemaakte fout in dit hele domein, juist omdat on-premises AD nesting wél altijd liet werken. Wie zijn toegangsmodel op nesting bouwt, bouwt op zand; de moderne route is directe lidmaatschappen die door automatisering worden onderhouden.

Provisioning is een aparte stap

Toewijzing regelt authenticatie en zichtbaarheid, niet het account ín de applicatie. Apps die SCIM ondersteunen kunnen accounts automatisch laten aanmaken op basis van dezelfde toewijzing (Provisioning in het app-menu); apps zonder SCIM hebben een eigen route nodig. Verwar de twee niet: een gebruiker kan toegewezen zijn en toch geen werkend account hebben, of andersom een achtergebleven account houden nadat de toewijzing is ingetrokken.

Waarom je dit met Joinly doet

Het model staat of valt met de vulling van de toegangsgroepen. Handmatig bijgehouden lidmaatschappen lopen achter op de werkelijkheid: de nieuwe collega wacht op toegang, de vertrokken collega houdt hem. En de nestingbeperking dwingt je tot vlakke groepen, wat zonder automatisering betekent dat elke functiewisseling in meerdere groepen tegelijk verwerkt moet worden.

De Joinly AD agent wijst de lidmaatschappen rechtstreeks toe vanuit business rules op je HR data: functie en afdeling bepalen welke app-groepen iemand in zit, in Entra én on-premises AD. Indiensttreding, functiewisseling en vertrek muteren de toegang automatisch, met audit trail. En voor applicaties zonder SCIM neemt Joinly ook de accountprovisioning mee, zodat toewijzing en account nooit uit de pas lopen.

Wil je weten welke apps in jouw tenant zonder assignment requirement openstaan? De gratis scan op scan.joinly.app brengt het in kaart.

Installation guide

Stap 1: Zet de toegangspoort aan

1. Ga naar entra.microsoft.com → Entra ID → Enterprise applications en open de applicatie.

2. Kies Properties en zet Assignment required? op Yes. Sla op.

Stap 2: Wijs de groep toe

1. Kies Users and groups → Add user/group.

2. Selecteer je toegangsgroep (bijvoorbeeld APP-Exact-Gebruiker).

3. Ondersteunt de app rollen, kies dan bij Select a role de juiste app role.

4. Klik Assign.

Stap 3: Herhaal per rechtniveau

Meerdere rollen in de app betekent meerdere groepen: één toewijzing per combinatie groep plus rol. Houd de naamconventie strak (APP-Exact-Gebruiker, APP-Exact-Beheer) zodat de ledenlijst zichzelf uitlegt.

Stap 4: Controleer de gebruikerservaring

Laat een testgebruiker inloggen op myapps.microsoft.com: de app hoort daar te verschijnen en te openen. Verwijder daarna het lidmaatschap en controleer dat de toegang ook echt verdwijnt.

Alternatief: via PowerShell/Graph

powershell

Connect-MgGraph -Scopes "Application.ReadWrite.All","AppRoleAssignment.ReadWrite.All"

$sp    = Get-MgServicePrincipal -Filter "displayName eq 'Exact'"
$group = Get-MgGroup -Filter "displayName eq 'APP-Exact-Gebruiker'"
$role  = $sp.AppRoles | Where-Object { $_.DisplayName -eq "User" }

New-MgGroupAppRoleAssignment -GroupId $group.Id `
  -PrincipalId $group.Id -ResourceId $sp.Id -AppRoleId $role.Id

Zo doe je dit in Joinly

In Joinly koppel je de app-groepen aan rollen in het autorisatiemodel: de business rule "afdeling Finance, functie Medewerker" bevat het lidmaatschap van APP-Exact-Gebruiker. De AD agent voert de directe lidmaatschappen uit en houdt ze bij; HR mutaties werken binnen minuten door in de app-toegang, inclusief het intrekken bij vertrek. Elke wijziging is terug te vinden in de audit trail, wat de vraag van de auditor ("wie had wanneer toegang tot dit pakket?") reduceert tot een export.