Hoe en waarom toepassingen worden toegevoegd aan Azure Active Directory

Er zijn twee weergaven van toepassingen in Azure AD:

  • Toepassingsobjecten : hoewel er uitzonderingen zijn, kunnen toepassingsobjecten worden beschouwd als de definitie van een toepassing.
  • Service-principals : kan worden beschouwd als een exemplaar van een toepassing. Service-principals verwijzen over het algemeen naar een toepassingsobject en één toepassingsobject kan worden verwezen door meerdere service-principals in mappen.

Wat zijn toepassingsobjecten en waar komen ze vandaan?

U kunt toepassingsobjecten in de Azure Portal beheren via de ervaring App-registraties. Toepassingsobjecten beschrijven de toepassing in Azure AD en kunnen worden beschouwd als de definitie van de toepassing, zodat de service kan weten hoe tokens aan de toepassing moeten worden uitgeven op basis van de instellingen. Het toepassingsobject bestaat alleen in de basismap, zelfs als het een toepassing met meerdere tenants is die service-principals in andere mappen ondersteunt. Het toepassingsobject kan een van de volgende gegevens bevatten (evenals aanvullende informatie die hier niet wordt vermeld):

  • Naam, logo en uitgever
  • Omleidings-URI's
  • Geheimen (symmetrische en/of asymmetrische sleutels die worden gebruikt om de toepassing te verifiëren)
  • API-afhankelijkheden (OAuth)
  • Gepubliceerde API's/resources/bereiken (OAuth)
  • App-rollen (RBAC)
  • Metagegevens en configuratie van eenmalige aanmelding
  • Metagegevens en configuratie van gebruikersinrichting
  • Proxymetagegevens en -configuratie

Toepassingsobjecten kunnen worden gemaakt via meerdere paden, waaronder:

  • Toepassingsregistraties in de Azure Portal
  • Een nieuwe toepassing maken met behulp van Visual Studio en deze configureren voor het gebruik van Azure AD-verificatie
  • Wanneer een beheerder een toepassing toevoegt vanuit de app-galerie (waarmee ook een service-principal wordt gemaakt)
  • Microsoft Graph API of PowerShell gebruiken om een nieuwe toepassing te maken
  • Veel andere, waaronder verschillende ontwikkelaarservaringen in Azure en in API Explorer-ervaringen in ontwikkelaarscentra

Wat zijn service-principals en waar komen ze vandaan?

U kunt service-principals in de Azure Portal beheren via de ervaring bedrijfstoepassingen. Service-principals bepalen wat een toepassing bepaalt die verbinding maakt met Azure AD en kan worden beschouwd als het exemplaar van de toepassing in uw directory. Voor elke toepassing kan deze maximaal één toepassingsobject hebben (dat is geregistreerd in een 'basismap') en een of meer service-principal-objecten die exemplaren van de toepassing vertegenwoordigen in elke map waarin deze zich gedraagt.

De service-principal kan het volgende omvatten:

  • Een verwijzing naar een toepassingsobject via de eigenschap toepassings-id
  • Records van lokale gebruikers- en groepstoepassingsroltoewijzingen
  • Records van lokale gebruikers- en beheerdersmachtigingen die aan de toepassing zijn verleend
    • Bijvoorbeeld: machtiging voor de toepassing voor toegang tot het e-mailadres van een bepaalde gebruiker
  • Records van lokaal beleid, inclusief beleid voor voorwaardelijke toegang
  • Records van alternatieve lokale instellingen voor een toepassing
    • Claimtransformatieregels
    • Kenmerktoewijzingen (gebruikersinrichting)
    • Directoryspecifieke app-rollen (als de toepassing aangepaste rollen ondersteunt)
    • Mapspecifieke naam of logo

Net als toepassingsobjecten kunnen service-principals ook worden gemaakt via meerdere paden, waaronder:

  • Wanneer gebruikers zich aanmelden bij een toepassing van derden die is geïntegreerd met Azure AD
    • Tijdens het aanmelden wordt gebruikers gevraagd toestemming te geven aan de toepassing om toegang te krijgen tot hun profiel en andere machtigingen. De eerste persoon die toestemming geeft, zorgt ervoor dat een service-principal die de toepassing vertegenwoordigt, wordt toegevoegd aan de directory.
  • Wanneer gebruikers zich aanmelden bij Microsoft onlineservices zoals Microsoft 365
    • Wanneer u zich abonneert op Microsoft 365 of een proefversie start, worden een of meer service-principals gemaakt in de directory die de verschillende services vertegenwoordigen die worden gebruikt voor het leveren van alle functionaliteit die is gekoppeld aan Microsoft 365.
    • Sommige Microsoft 365 services, zoals SharePoint, maken doorlopend service-principals om veilige communicatie tussen onderdelen, inclusief werkstromen, mogelijk te maken.
  • Wanneer een beheerder een toepassing toevoegt vanuit de app-galerie (hiermee wordt ook een onderliggend app-object gemaakt)
  • Een toepassing toevoegen voor het gebruik van de Azure AD-toepassingsproxy
  • Verbinding maken een toepassing voor eenmalige aanmelding met behulp van SAML of wachtwoord voor eenmalige aanmelding (SSO)
  • Programmatisch via microsoft Graph API of PowerShell

Een toepassing heeft één toepassingsobject in de basismap waarnaar wordt verwezen door een of meer service-principals in elk van de mappen waar deze actief is (inclusief de basismap van de toepassing).

Shows relationship between app objects and service principals

In het voorgaande diagram onderhoudt Microsoft twee mappen intern (weergegeven aan de linkerkant) die worden gebruikt voor het publiceren van toepassingen:

  • Een voor Microsoft Apps (Microsoft-services directory)
  • Een voor vooraf geïntegreerde toepassingen van derden (app-galeriemap)

Uitgevers/leveranciers van toepassingen die integreren met Azure AD zijn vereist om een publicatiemap te hebben (rechts weergegeven als 'Sommige SaaS-directory').

Toepassingen die u zelf toevoegt (weergegeven als App (uwe) in het diagram, zijn onder andere:

  • Apps die u hebt ontwikkeld (geïntegreerd met Azure AD)
  • Apps die u hebt verbonden voor eenmalige aanmelding
  • Apps die u hebt gepubliceerd met behulp van de Azure AD-toepassingsproxy

Notities en uitzonderingen

  • Niet alle service-principals wijzen terug naar een toepassingsobject. Toen Azure AD oorspronkelijk werd gebouwd, waren de services die aan toepassingen werden geleverd, beperkter en was de service-principal voldoende voor het tot stand brengen van een toepassingsidentiteit. De oorspronkelijke service-principal was dichter bij het Windows Server Active Directory serviceaccount. Daarom is het nog steeds mogelijk om service-principals te maken via verschillende paden, zoals het gebruik van Azure AD PowerShell, zonder eerst een toepassingsobject te maken. Microsoft Graph API vereist een toepassingsobject voordat u een service-principal maakt.
  • Niet alle hierboven beschreven informatie wordt momenteel programmatisch weergegeven. De volgende zijn alleen beschikbaar in de gebruikersinterface:
    • Claimtransformatieregels
    • Kenmerktoewijzingen (gebruikersinrichting)
  • Zie de referentiedocumentatie voor Microsoft Graph API voor meer informatie over de service-principal en toepassingsobjecten:

Waarom kunnen toepassingen worden geïntegreerd met Azure AD?

Toepassingen worden toegevoegd aan Azure AD om gebruik te maken van een of meer van de services die het biedt, waaronder:

  • Verificatie en autorisatie van toepassingen
  • Gebruikersverificatie en autorisatie
  • Eenmalige aanmelding met federatie of wachtwoord
  • Gebruikersinrichting en synchronisatie
  • Op rollen gebaseerd toegangsbeheer- Gebruik de directory om toepassingsrollen te definiëren om verificatiecontroles op basis van rollen uit te voeren in een toepassing
  • OAuth-autorisatieservices - gebruikt door Microsoft 365 en andere Microsoft-toepassingen om toegang te verlenen tot API's/resources
  • Toepassing publiceren en proxy- een toepassing publiceren van een particulier netwerk naar internet
  • Kenmerken van directoryschema-extensie: het schema van service-principal en gebruikersobjecten uitbreiden om aanvullende gegevens op te slaan in Azure AD

Wie is gemachtigd om toepassingen toe te voegen aan mijn Azure AD-exemplaar?

Hoewel er enkele taken zijn die alleen globale beheerders kunnen uitvoeren (zoals het toevoegen van toepassingen uit de app-galerie en het configureren van een toepassing voor het gebruik van de toepassingsproxy) hebben alle gebruikers in uw directory standaard rechten om toepassingsobjecten te registreren die ze ontwikkelen en naar eigen goeddunken over welke toepassingen ze delen of toegang geven tot hun organisatiegegevens via toestemming. Als een persoon de eerste gebruiker in uw directory is om u aan te melden bij een toepassing en toestemming te verlenen, wordt er een service-principal in uw tenant gemaakt; anders wordt de toestemmingstoestemmingsgegevens opgeslagen in de bestaande service-principal.

Gebruikers toestaan om toepassingen te registreren en toestemming te geven, kunnen in eerste instantie goed klinken, maar houd rekening met het volgende:

  • Toepassingen kunnen al vele jaren gebruikmaken van Windows Server Active Directory voor gebruikersverificatie zonder dat de toepassing hoeft te worden geregistreerd of vastgelegd in de directory. Nu heeft de organisatie de zichtbaarheid verbeterd van het aantal toepassingen dat gebruikmaakt van de directory en voor welk doel.
  • Door deze verantwoordelijkheden aan gebruikers te delegeren, wordt de noodzaak voor registratie en publicatie van een toepassing op basis van een beheerder ontkend. Met Active Directory Federation Services (ADFS) was het waarschijnlijk dat een beheerder een toepassing moest toevoegen als relying party namens hun ontwikkelaars. Ontwikkelaars kunnen nu selfservice gebruiken.
  • Gebruikers die zich aanmelden bij toepassingen die hun organisatieaccounts gebruiken voor zakelijke doeleinden, zijn handig. Als ze vervolgens de organisatie verlaten, verliezen ze automatisch de toegang tot hun account in de toepassing die ze gebruikten.
  • Een record hebben van welke gegevens zijn gedeeld met welke toepassing is een goed ding. Gegevens zijn transporteerbaarer dan ooit en het is handig om een duidelijk overzicht te hebben van wie welke gegevens met welke toepassingen hebben gedeeld.
  • API-eigenaren die Azure AD voor OAuth gebruiken, bepalen precies welke machtigingen gebruikers kunnen verlenen aan toepassingen en welke machtigingen een beheerder nodig heeft om akkoord te gaan. Alleen beheerders kunnen toestemming geven voor grotere bereiken en meer belangrijke machtigingen, terwijl gebruikerstoestemming is afgestemd op de eigen gegevens en mogelijkheden van de gebruikers.
  • Wanneer een gebruiker een toepassing toevoegt of toestaat om toegang te krijgen tot de gegevens, kan de gebeurtenis worden gecontroleerd, zodat u de auditrapporten in de Azure Portal kunt bekijken om te bepalen hoe een toepassing is toegevoegd aan de map.

Als u nog steeds wilt voorkomen dat gebruikers in uw directory toepassingen registreren en zich zonder goedkeuring door de beheerder aanmelden bij toepassingen, zijn er twee instellingen die u kunt wijzigen om deze mogelijkheden uit te schakelen:

Notitie

Microsoft zelf gebruikt de standaardconfiguratie waarmee gebruikers toepassingen kunnen registreren en alleen gebruikerstoestemming voor een zeer beperkte set machtigingen toestaat.