Vervang service-principalprofielen door service-principals

Als uw oplossing gebruikmaakt van service-principalprofielen (SPP) en de beperkingen ervan op het gebied van identiteit, governance, API of bedrijfsvoering uw vereisten beperken, helpt deze handleiding u bij het evalueren en implementeren van een vervanging op basis van toegewezen Microsoft Entra service-principals. Als uw bestaande oplossing op basis van een profiel voldoet aan uw vereisten, kunt u deze blijven gebruiken.

Voor klanten die ervoor kiezen te migreren, worden in deze handleiding beheerde identiteit en federatieve referenties aanbevolen als aan de vereisten voor hosting en vertrouwen is voldaan. Directe authenticatie van de service-principal blijft een alternatief. Beide paden bieden toegewezen klantidentiteiten voor directorygovernance, onafhankelijke controle van aanmelden en toegang tot ondersteunde services buiten profielbewuste interfaces.

Note

Als u een nieuwe toepassing bouwt, begint u met Multitenancy met toegewezen service-principals en volgt u het identiteitspatroon en de implementatiehandleiding. Profielinventaris- en buitengebruikstellingsfasen zijn alleen van toepassing op bestaande op profielen gebaseerde toepassingen.

Waarom migreren vanuit profielen

Overweeg profielen te vervangen wanneer de volgende beperkingen uw oplossing beperken:

  • Profielen voldoen niet aan Microsoft Entra ID aanbevolen procedures voor beheerbare workloadidentiteiten. Een profiel heeft geen representatie in Microsoft Entra ID. Het produceert geen onafhankelijke aanmeldingslogboeken, kan geen eigen beleid voor voorwaardelijke toegang bevatten en kan niet worden beheerd door de hulpprogramma's die worden gebruikt voor de rest van de identiteitsomgeving.

U kunt bijvoorbeeld geen profiel configureren als de identiteit van een Direct Lake-verbinding van een semantisch model naar een lakehouse of warehouse. U kunt het ook geen toegang verlenen als een onafhankelijke Microsoft Entra-identiteit tot andere downstreamservices die de toepassing of de bijbehorende workloads moeten gebruiken. Een afzonderlijke service-principal kan deze machtigingen ontvangen waar de service deze ondersteunt.

U kunt geen profielen gebruiken met de Fabric REST API's. Profielen worden alleen ondersteund door de profile-aware REST API, de .NET SDK en ondersteunde XMLA/TOM-interfaces. De Fabric REST API's bieden geen ondersteuning voor profielen en ondersteuning is niet gepland. Gebruik een ondersteunde identiteit voor deze API-aanroepen in plaats van een profiel. Het maken van een toegewezen service-principal voldoet aan de identiteitsvereiste, maar elke API en bewerking moeten die identiteit nog steeds ondersteunen en deze de benodigde machtigingen verlenen.

  • Verificatie blijft gekoppeld aan de bovenliggende identiteit. Wanneer het bovenliggende item een geheim of certificaat gebruikt, beveilig en roteer dan die aanmeldingsgegeven. Het aanbevolen vervangingspatroon voorkomt opgeslagen inloggegevens van klanttoepassingen. Profielen kunnen ook een bovenliggende beheerde identiteit gebruiken, dus geheimloze verificatie op zichzelf vereist geen vervanging van profielen. Een bovenliggende beheerde identiteit geeft de profielen geen onafhankelijke directory-identiteiten of bredere API-ondersteuning.

Profielen lossen een schaalprobleem op, niet een probleem van onafhankelijke identiteit. Eén bovenliggende service-principal kan maximaal 100.000 profielen maken en elk profiel kan maximaal 1.000 werkruimten openen of maken. Een service-principal zelf kan in dit model tot maximaal 1000 werkruimten behoren. Dedicated klantidentiteiten verbruiken in plaats daarvan Microsoft Entra-mapobjecten. Valideer de toepasselijke limieten aan de hand van uw klantenaantal voordat u de migratie doorvoert.

Note

Beveiligingsgrens: Een profiel is geen cryptografische klantscheiding: de bovenliggende service-principal kan via elk van zijn profielen handelen. Met het aanbevolen patroon kan de beheerde runtime-identiteit zich ook authenticeren als een klanttoepassing die deze vertrouwt. Werkruimte- en resourcemachtigingen blijven de afgedwongen autorisatiegrens. Beveilig de runtime- en klant-naar-identiteittoewijzing in elk van beide modellen.

Andere profielbeperkingen om rekening mee te houden

Beperking Gevolgen van migratie
Geen onafhankelijke controle- of beleidsentiteit Een profiel heeft geen onafhankelijke Microsoft Entra-aanmeldingsregistratie of doel voor voorwaardelijke toegang voor workloadidentiteit. Dedicated service-principals bieden deze mogelijkheden, afhankelijk van de geschiktheid van het beleid en licenties.
Permanente koppeling van profiel aan bovenliggend item Profielen kunnen niet worden overgedragen naar een andere bovenliggende service-principal. Voor het vervangen van de bovenliggende zijn nieuwe profielen, nieuwe werkruimtetoekenningen en bijgewerkte klanttoewijzingen vereist.
Geen portal voor identiteitsbeheer Profielen zijn alleen via API beschikbaar en worden niet weergegeven in Microsoft Entra-beheerprogramma's. Specifieke toepassingen en service-principals hebben directoryzichtbaarheid en beheeroppervlakken.

Het patroon van beheerde identiteit en gefedereerde referenties

Gebruik dit patroon voor een nieuwe dedicated-principal-oplossing of wanneer u ervoor kiest om profielen te vervangen, mits uw runtime voldoet aan de hostingvereisten voor beheerde identiteiten.

Het patroon

Geef elke klant een echte Microsoft Entra service-principal en gebruik de beheerde identiteit van de toepassing als een assertiebron. Deze benadering vervangt zowel de aanmeldingsgegevens van de gedeelde toepassing als de profielabstractie. U kunt elke klantidentiteit registreren, beheren en beoordelen voor voorwaardelijke toegang voor workloadidentiteiten, en deze kan ondersteunde Fabric REST API's aanroepen.

Deze benadering is het aanbevolen migratiepad wanneer de Azure-hosting- en vertrouwensvereisten bij de oplossing passen. Hiermee worden opgeslagen aanmeldingsgegevens van de klanttoepassing en hun rotatieprocessen verwijderd zonder te wijzigen waar werkruimte- en resourceautorisatie wordt afgedwongen.

De architectuur toont de runtimebewerkingen van de toepassing, drie klanttoepassingsidentiteiten en vertrouwensrelaties, en de een-op-een-relaties van klantwerkruimten. Dit vormt de standaardopzet voor gedeelde runtime, niet een nieuwe isolatiescheiding.

Diagram van een ISV-toepassing die een beheerde identiteitstoken verkrijgt, deze uitwisselt voor een geselecteerd token van de klanttoepassing en doel-API's aanroept. Afzonderlijke service-principals van klant A, B en C hebben gefedereerd vertrouwen in de door de toepassing beheerde identiteit en hebben alleen toegang tot hun bijbehorende klantwerkruimten.

Afbeelding 1. Eén door de toepassing beheerde identiteit wordt geverifieerd als service-principals van klanten die aan één klant zijn toegewezen.

Hoe werkt het?

  1. Door de toepassing beheerde identiteit. Wijs een door de gebruiker toegewezen beheerde identiteit toe aan de ISV-toepassing die wordt uitgevoerd op ondersteunde Azure compute, zoals App Service, Container Apps, een correct geconfigureerde AKS-workload of een virtuele machine. Gebruik één beheerde identiteit voor de toepassing, niet één per klant. Het heeft geen eigen machtigingen voor de werkruimte of doelservice; de rol hier is alleen om een assertion te leveren.

  2. service-principals per klant, per gebruiker of per groep. Maak voor elke bestaande klant- of autorisatiegrens een Microsoft Entra toepassingsregistratie en service-principal in de directorytenant van de ISV. Een logische klant betekent niet noodzakelijkerwijs een afzonderlijke Microsoft Entra tenant en een identiteit per eindgebruiker is niet vereist, tenzij het bestaande toegangsontwerp dit vereist.

  3. Federatieve identiteitsreferentie. Configureer op elke toepassingsregistratie van de klant een federatieve identiteitsreferentie om de beheerde identiteit van de toepassing te vertrouwen. De runtime kan vervolgens het beheerde identiteitstoken gebruiken als een assertie om een toegangstoken voor die klanttoepassing te verkrijgen zonder een clientgeheim of certificaat.

  4. Uitwisseling van runtimetokens. Wanneer gebruiker A of een klantspecifieke taak de toepassing aanroept, identificeert u klant A via een vertrouwde toewijzing aan de serverzijde. Verwerf het beheerde identiteitstoken met audience api://AzureADTokenExchange; wissel het in voor een toegangstoken als SP-A; roep vervolgens de doel-API's aan met behulp van het token van SP-A om werkruimten te beheren, resourcebewerkingen uit te voeren of waar nodig toepassingsspecifieke tokens aan te vragen.

    Voor de uitwisseling in de vorige stap accepteert de .NET Azure Identity ClientAssertionCredential het token van de beheerde identiteit als client assertion. Dit is een Azure Identity-referentietype, geen MSAL-klasse. Het toegangstoken moet bedoeld zijn voor de doelgroep van de resource-API, niet voor de tokenuitwisselingsdoelgroep.

  5. Toegang tot workspace. Verleen elke service-principal alleen de rol Lid of Beheerder voor de toegewezen werkruimten wanneer deze rollen nodig zijn, of wijs de minst bevoegde ondersteunde rol toe die nodig is voor de vereiste bewerkingen. Die machtiging bepaalt de toegang tot resources. Omdat de beheerde identiteit van de toepassing zich kan authenticeren als elke klanttoepassing die deze vertrouwt, behandelt u deze en de rekenhosts als hoogwaardige identiteiten en infrastructuur.

  • Minder langlevende inloggegevens. U hoeft geen toepassingsgeheim van de klant of persoonlijke sleutel van het certificaat op te slaan, op te halen of te distribueren naar de runtime.

  • Minder rotatiewerk. Azure beheert de referenties van de beheerde identiteit en geeft kortdurende tokens uit. U hebt geen afzonderlijk geheim of certificaatvernieuwingsproces nodig voor elke klanttoepassing die deze trust gebruikt.

  • Consistent onboarding. Richt een klanttoepassing en service-principal in, definieer de expliciete vertrouwensrelatie en verleen klantresourcetoegang. Nieuwe klanten hebben geen nieuwe inloggegevens met een lange levensduur nodig.

Deze voordelen nemen de noodzaak voor vertrouwensbeheer, klantautorisatie, auditbewaking of planning van directorycapaciteit niet weg.

Alternatief: Directe authenticatie van service principal

Als u geen beheerde identiteit en gefedereerde referenties wilt gebruiken, maakt u dezelfde specifieke registraties van klanttoepassingen en service-principals, maar authenticeert u deze rechtstreeks met certificaten of andere ondersteunde toepassingsreferenties. Geef de voorkeur aan certificaten boven clientgeheimen waar deze worden ondersteund. Beveilig privésleutels en geheimen, beperk de toegang tot deze sleutels en automatiseer rotatie.

Directe authenticatie behoudt de zichtbaarheid van directory's, aanmeldingslogboeken per principal en toegang tot ondersteunde API's. Er is geen hosting- of vertrouwensrelatie voor beheerde identiteiten vereist, maar het elimineert geen opgeslagen klantaanmeldingsgegevens.

Belangrijke concepten

Onderscheid maken tussen de inloggegevens die vertrouwen tot stand brengen en de tokens die tijdens runtime worden gebruikt.

Gefedereerde identiteitsgegevens

Stel een federatieve identiteitsreferentie (FIC) in op de Microsoft Entra toepassingsregistratie die de service-principal van de klant ondersteunt. Het definieert een vertrouwensrelatie met een tokenverlener en geeft aan welke verklaring de toepassing accepteert in plaats van een clientgeheim of certificaat.

In deze architectuur is de doelidentiteit de klanttoepassing en service-principal; de beheerde identiteit van de toepassing is de assertiebron. Daarom configureert u het aanmeldingsgegeven van de klant voor de registratie van de toepassing in plaats van op het service-principal-object of de beheerde identiteit van de bron.

Note

Configuratie-onderscheid: Federatieve identiteitsreferenties worden ook ondersteund voor door de gebruiker toegewezen beheerde identiteiten in andere federatiescenario's. Dit verandert het patroon hier niet: configureer het vertrouwen bij elke registratie van de klanttoepassing. Alleen een door de gebruiker toegewezen beheerde identiteit wordt ondersteund als bron voor de assertie van beheerde identiteit in het app-vertrouwenspatroon dat in deze handleiding wordt beschreven.

Trust-veld Waarde in de globale cloud
Issuer https://login.microsoftonline.com/{directory-tenant-id}/v2.0
Subject De principal-id (object) van de door de gebruiker toegewezen beheerde identiteit. Gebruik de client-id ervan niet.
Audiëntie api://AzureADTokenExchange

Wanneer de toepassing het beheerde identiteitstoken presenteert en een toegangstoken aanvraagt voor de klanttoepassing, valideert Microsoft Entra ID de assertie op basis van de gefedereerde referentie. De verstrekker, het onderwerp en de doelgroep moeten overeenkomen. Als de validatie slaagt, geeft het een toegangstoken uit dat de service-principal van de doelklant vertegenwoordigt voor de aangevraagde resource.

De registratie van de beheerde identiteit en de registratie van de vertrouwende toepassing moeten zich in dezelfde Microsoft Entra-tenant bevinden. De resource audience is een afzonderlijke keuze van de assertie-doelgroep. Voor Azure Identity is api://AzureADTokenExchange/.default het bereik van de global-cloud-token-exchange; het doel-API-bereik is normaal gesproken de resource-id gevolgd door /.default.

Stroom voor tokenuitwisseling: clientgegevens met een federatieve assertie

Deze flow omvat drie deelnemers en zes stappen. SP-A is de toepassing en service-principal van klant A. Het assertietoken van de beheerde identiteit en het geretourneerde SP-A toegangstoken voor resources dienen verschillende doeleinden.

Sequentiediagram met een Azure-toepassing die een beheerd identiteitstoken aanvraagt en ontvangt, een aanvraag voor clientreferenties verzendt met de client-id van SP-A en het beheerde identiteitstoken als een assertie, waarbij Microsoft Entra ID het federatieve vertrouwen valideert, het toegangstoken van SP-A retourneert en de toepassing de doel-API aanroept als SP-A.

Afbeelding 2. Tokenuitwisseling van clientreferenties die wordt ondersteund door een assertie van een beheerde identiteit.

  1. Vraag het token van de beheerde identiteit aan. De app op Azure vraagt een token voor een beheerde identiteit aan met audience api://AzureADTokenExchange.

  2. Retourneer het assertietoken. Microsoft Entra ID geeft het token van de beheerde identiteit uit, dat de app ontvangt via het beheerde identiteitsmechanisme van de Azure hostomgeving.

  3. Dien de aanvraag van het klanttoken in. Verzend een aanvraag naar het eindpunt van de maptenant /oauth2/v2.0/token met grant_type=client_credentials, client_id=<SP-A-client-id>, client_assertion=<MI-token> en scope=<target-resource>/.default. De volledige OAuth-aanvraag levert client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer ook; een identiteitsbibliotheek verwerkt deze parameter.

  4. Controleer de assertie. Microsoft Entra ID valideert het beheerde identiteitstoken ten opzichte van de federatieve referentiegegevens in de toepassingsregistratie van SP-A.

  5. Retourneer het toegangstoken van de klant. Microsoft Entra ID retourneert een toegangstoken voor SP-A met de doelresource als audience.

  6. Roep de doel-REST-API's aan. De app verzendt het toegangstoken van SP-A naar de doel-API. Het gebruikt het assertietoken niet als het bearer-token van de resource en selecteert geen profiel.

Architectuurvergelijking

De vervangende kolom omvat over het algemeen speciale service-principals. Beheerde identiteit en federatie zijn de aanbevolen authenticatiemethode, maar directe authenticatie met een certificaat of andere ondersteunde authenticatie met aanmeldingsgegevens is ook mogelijk.

Aspect Service principal-profielen Specifieke service principals
Identiteit per klant Logisch profiel, geen Microsoft Entra-object. App-registratie en service-principal die de grens voor klantautorisatie vertegenwoordigen.
Afgedwongen limiet Machtigingen voor werkruimten en resources Machtigingen voor werkruimten en resources
Bereik van root identity De bovenliggende service-principal kan fungeren als elk van zijn profielen. Een runtime kan alle identiteiten bereiken waarvoor deze referenties of vertrouwde asserties heeft; een MI kan zich authenticeren als elke app die deze vertrouwt.
Geheime draaiing Vereist wanneer het bovenliggende object een geheim of certificaat gebruikt. Niet vereist voor aanmeldingsgegevens van beheerde identiteiten; vereist voor opgeslagen certificaten of clientgeheimen op het directe pad.
Bovengrens van schaling Maximaal 100.000 profielen per bovenliggende SP; elk profiel ondersteunt maximaal 1.000 werkruimten. Het eigen lidmaatschap van de bovenliggende SP is beperkt tot 1000 werkruimtes. Een toepassingsregistratie en service-principal per klant, afhankelijk van quota voor directoryobjecten en resourcelimieten van elke doelservice.
Controlelogboek Profiel-id's worden mogelijk weergegeven in resourcelogboeken, maar profielen hebben geen onafhankelijke Microsoft Entra aanmeldingsrecord. Microsoft Entra aanmeldingsrecords per service-principal, gecorreleerd met auditlogboeken voor toepassingen en resources.
Voorwaardelijke toegang Geen beleid voor workloadidentiteit per profiel. Het beleid is beschikbaar voor in aanmerking komende service-principals met Microsoft Entra Workload-id Premium. Het beleid moet rechtstreeks op elke principal zijn gericht.
Zichtbaarheid van het portaal Niet aanwezig in Microsoft Entra ID. App-registratie in App-registraties; service-principal in Enterprise applications.
Fabric REST API-ondersteuning Niet ondersteund; ondersteuning is niet gepland. Ondersteund waarbij de specifieke API en bewerking service-principals accepteren, met vereiste machtigingen.
Overdracht van referentiegegevens en bovenliggende/onderliggende koppeling Een profiel kan niet worden overgedragen tussen bovenliggende service-principals. Gefedereerd vertrouwen kan opnieuw worden geconfigureerd; directe inloggegevens kunnen worden vervangen zonder een profielabstractie opnieuw te maken.

Hoe u deze tabel leest: geen van beide configuraties biedt cryptografische isolatie van klanten. Resourcemachtigingen dwingen toegang af en de runtime kan indirect toegang hebben over klantgrenzen heen. Profielen bieden lichtgewicht schaalbaarheid voor identiteiten. Dedicated principals verbeteren directorybeheer, zichtbaarheid van aanmeldingen en API-compatibiliteit. Met het aanbevolen pad voor beheerde identiteit en federatie worden ook de opgeslagen referenties van klanttoepassingen verwijderd.

Migratiepad

Het volgende pad vervangt profielen door toegewijde klantenservice-principals. Houd de beslissingen voor migratie en terugdraaien gescheiden voor elke klant.

Van profielen tot beheerde identiteit en gefedereerde referenties

Gebruik de volgende migratiefasen met een klein pilotcohort en een switch voor uitrol per klant. Houd de profielroute beschikbaar totdat de validatie en de overeengekomen terugdraaiperiode zijn voltooid.

Fase 0: De beheerde identiteit van de toepassing maken

  • Maak de door de gebruiker toegewezen beheerde identiteit voor de toepassing en wijs deze toe aan de rekenresource. In de implementatiehandleiding ziet u de opdrachten voor het maken en toewijzingsopdrachten.

  • Noteer de object-id van de principal. De gefedereerde referentie van elke klanttoepassing gebruikt deze waarde als subject. Noteer ook de client-id, de tenant-id van de directory en Azure resource-id.

Gebruik één beheerde identiteit voor de toepassing, niet één per klant. Een afzonderlijke MI voor elke klant is overbodig in dit patroon: de klantidentiteit is de service-principal en de MI levert de assertie. Voor grotere implementaties of een kleinere impact bij compromittering kunt u klanten partitioneren over een klein aantal runtime-identiteiten, die elk alleen worden vertrouwd door de toegewezen subset van klanttoepassingen.

Fase 1: Inventaris

Alle bestaande profielen weergeven via de API voor profielbeheer:

GET {profile-api-base}/v1.0/myorg/profiles

Voor elk profiel moet u het volgende opnemen:

  • Profiel-id en weergavenaam, bovenliggende service-principal en klanttoewijzing.

  • Gekoppelde werkruimten en roltoewijzingen.

  • Gekoppelde semantische modellen of gegevenssets, rapporten en andere resources.

  • Verbindingen, aanmeldingsgegevens van de gegevensbron, eigendomsafhankelijkheden, achtergrondtaken en API-bewerkingen die afhankelijk zijn van het profiel.

Voordat u de configuratie van een klant wijzigt, registreert u de bestaande werkruimterollen, semantisch modeleigendom, verbindingsidentiteiten, configuratie van aanmeldingsgegevens en toewijzing van klant-naar-profiel die nodig zijn voor terugdraaibewerking. Noteer beveiligde verwijzingen naar inloggegevens, niet geheime waarden.

Noteer het totale aantal klanten en vergelijk de vereiste toepassings- en service-principalobjecten met uw Microsoft Entra quota voor directoryobjecten voordat u doorgaat. Valideer ook de lidmaatschapslimiet van 1000 werkruimten en eventuele resourcespecifieke limieten. Als de populatie het quotum van één directory overschrijdt, moet u een ondersteunde quotumverhoging plannen of een bewust beheerde opzet met meerdere directory's ontwerpen; het wordt niet automatisch opgelost door dit patroon.

Note

Eindpunt notatie:{profile-api-base} geeft de bestaande profielbewuste REST API-basis-URL aan die al door uw oplossing wordt gebruikt. Houd die URL in uw deploymentconfiguratie. In deze voorbeelden blijven de uitvoeringspaden behouden; vervang elke placeholder voordat u deze uitvoert. De term profile-aware beschrijft API-ondersteuning, niet een deprecatiestatus.

Fase 2: Nieuwe identiteiten inrichten

Voor elk profiel of elke groep profielen die behoren tot dezelfde autorisatiegrens van dezelfde klant:

  1. Maak een app-registratie en service-principal. Noteer de client-id van de toepassing, de object-id van de toepassing en de object-id van de service-principal afzonderlijk.

  2. Configureer een federatieve aanmeldingsreferentie op de registratie van de klanttoepassing die de toepassings-MI vertrouwt die in fase 0 is gemaakt.

  3. Geef de nieuwe service-principal toegang tot dezelfde werkruimten en resources van de klant. Gebruik Member waarvoor de geïnventariseerde bewerkingen dit vereisen of de minst bevoegde ondersteunde rol. Verleen alleen adminrechten wanneer dat nodig is.

Houd bestaande werkruimte- en resource-id's waar dit wordt ondersteund. Een werkruimtetoekenning draagt niet automatisch het eigendom van resources, verbindingsidentiteiten of aanmeldingsgegevens van gegevensbronnen over. Voltooi deze servicespecifieke updates vóór de cutover.

Fase 3: Toepassingscode bijwerken

  • Vervang de profielselectieheader- en SDK-profielconfiguratie door een op beheerde identiteit gebaseerde tokenuitwisseling voor de geselecteerde klanttoepassing.

  • Werk de toewijzing van de klant-naar-identiteit in uw toepassingsdatabase bij.

Voordat Na
customerId -> profileId met één gedeelde SP-referentie en een profielheader. customerId -> spClientId met SP-verificatie per klant via exchange van beheerde identiteitstokens. Bewaar ook de directorytenant-id, verificatieconfiguratie en toegestane resource-id's.

Klant-id's zijn logische id's van ISV-klanten, niet noodzakelijkerwijs Microsoft Entra tenant-id's. Valideer het klantlidmaatschap van de geauthenticeerde gebruiker voordat u een identiteit selecteert. Sleuteltokencaches per directory-tenant, client-id en resource of scope.

  • Toepassingsspecifieke tokengeneratie bijwerken om het toegangstoken van de klantservice-principal te gebruiken. Als uw oplossing rapporten of andere inhoud insluit, werkt u ook het genereren van dat token bij; insluiten is een bestaande workload die moet worden gemigreerd, niet een vereiste voor deze handleiding.

  • Werk werkruimtebeheer, downstreamverbindingen, provisioning, geplande taken en elk ander toegangspunt bij met behulp van de oude profielconfiguratie.

Fase 4: Valideren

Controleer voor elke klant het volgende:

  • Toegang tot werkruimten en resources is mogelijk via de nieuwe service-principal.

  • Het verkrijgen van beheerde identiteitstokens en federatieve tokenuitwisseling slagen voor de beoogde klanttoepassing.

  • Toepassingsspecifieke tokens worden gegenereerd wanneer deze worden gebruikt en waar van toepassing bestaande rapporten of andere ingesloten inhoud correct worden weergegeven.

  • Nieuwe aanmeldingen voor service-principals worden weergegeven in Microsoft Entra ID en kunnen worden gecorreleerd met auditlogboeken voor toepassingen en resources.

  • Toegang tussen klanten wordt geweigerd: een beller kan de toepassings-id of resource-id's van een andere klant niet selecteren.

Voordat u een productie-cutover gaat maken, documenteer en test u de terugdraaiprocedure voor een pilotklant. Neem het herstel op van eventueel semantisch modeleigendom, verbindingsidentiteiten, aanmeldingsgegevens voor gegevensbronnen en machtigingen die tijdens de migratie zijn gewijzigd. Controleer of het vorige profiel de vereiste bewerkingen kan uitvoeren na het terugdraaien, inclusief het vernieuwen van de configuratie en het bijwerken van parameters.

Schakel de applicatieroute van de klant pas over nadat aan de acceptatiecriteria is voldaan. Bewaak fouten, prestaties en machtigingen voordat u de implementatie uitbreidt.

Als de validatie mislukt, onderbreekt u de betrokken achtergrondtaken en herstelt u de vorige configuratie met behulp van de ondersteunde procedures voor elke service. Als u de toepassingsroute alleen terugzet naar het profiel, worden bewerkingen mogelijk niet hersteld die afhankelijk zijn van eigendom of aanmeldgegevens. Nadat u de vereiste configuratie hebt hersteld, gaat u terug naar de route op basis van het profiel en controleert u de toegang tot resources en afhankelijke bewerkingen voordat u taken hervat. Behoud de oorspronkelijke profielen en vereiste machtigingen gedurende de terugdraaiperiode.

Fase 5: Profielen buiten gebruik stellen

  • Na de terugdraaiperiode verwijdert u verouderde oorspronkelijke bovenliggende en machtigingen voor profielwerkruimten, nadat u hebt bevestigd dat de specifieke customer service-principals over de vereiste toegang beschikken.

Verwijder elk gemigreerd profiel via de API voor profielbeheer:

DELETE {profile-api-base}/v1.0/myorg/profiles/{profileId}
  • Verwijder desgewenst de oorspronkelijke registratie van de gedeelde toepassing en service-principal als geen enkele klant, taak of niet-gerelateerde workload er nog gebruik van maakt. Verouderde aanmeldgegevens buiten gebruik stellen en migratietoewijzingen en auditrecords behouden volgens uw retentievereisten.

Note

Alternatieve migratie zonder MI of federatie: Beheerde identiteit en gefedereerde referenties worden aanbevolen, niet verplicht. Als u deze niet wilt gebruiken, laat u fase 0 weg. Configureer in fase 2 een certificaat of andere ondersteunde aanmeldingsgegevens voor elke klanttoepassing in plaats van federatieve aanmeldingsgegevens. In fase 3 en 4 kunt u toegangstokens rechtstreeks als die toepassing verkrijgen en valideren. Behoud dezelfde inventaris, resourcetoekenningen, klantautorisatie, implementatie en buitengebruikstelling, en beveilig opslag en rotatie van inloggegevens.

Implementatiehandleiding

In deze handleiding wordt de aanbevolen route met beheerde identiteit en federatieve referenties geïmplementeerd. Het alternatief voor directe authenticatie volgt dezelfde identiteits- en machtigingsinstellingen en wordt beschreven na de belangrijkste stappen. Azure CLI voorbeelden gebruiken Bash-syntaxis; vervang tijdelijke aanduidingen en meld u aan bij de beoogde directory en het abonnement voordat u ze uitvoert.

Prerequisites

  • Een Azure-abonnement en machtigingen voor het maken en toewijzen van beheerde identiteiten voor het aanbevolen pad.

  • Machtigingen in Microsoft Entra ID om toepassingsregistraties en service-principals te maken en toepassingsreferenties bij te werken. Azure resourcemachtigingen en directorymachtigingen zijn gescheiden.

  • Een toepassing die wordt gehost op ondersteunde Azure compute, zoals App Service, Container Apps, een correct geconfigureerde AKS-workload of een virtuele machine. De door MI ondersteunde assertiebron in dit patroon is afhankelijk van die Azure hostingconfiguratie.

  • Beheerdersmachtigingen voor het verlenen van toegang tot de werkruimte en resource van de klant, het configureren van vereiste service-instellingen en het verlenen van API-machtigingen of toestemming wanneer de doelservice deze nodig heeft.

  • Azure CLI is geïnstalleerd en u bent aangemeld bij de juiste directory-tenant. Bevestig de abonnementscontext voordat u Azure resources maakt.

Tenantinstellingen voor ontwikkelaars

Controleer de relevante instellingen in de beheerinterface van uw service onder tenantinstellingen en instellingen voor ontwikkelaars. Beperk de toegang van de service-principal tot een toegestane beveiligingsgroep die de service-principals van de klant bevat. Zie tenantinstellingen voor ontwikkelaars voor de exacte labels en het huidige gedrag.

Voeg voor elke door uw oplossing vereiste instelling met groepsbereik de service-principal van elke vervangende klant toe aan een toegestane beveiligingsgroep voordat u test of cutover. Toegang die wordt verleend aan de oorspronkelijke bovenliggende service-principal, autoriseert de vervangende service-principals niet automatisch. De instelling voor toegang tot openbare API's is van toepassing op zowel de bestaande profile-aware REST API's als de Fabric REST API's; als u alleen de identiteit migreert, vervalt deze vereiste niet.

De volgende openbare API-instelling maakt gebruik van een productneutraal label; de beheerinterface kan de naam van de service bevatten.

Configuratie Gepubliceerd standaard Vereist wanneer
Service-principals kunnen openbare API's aanroepen Ingeschakeld voor nieuwe klanten. De beveiligingsprincipals van de klantenservice roepen de bestaande profielbewuste REST API's of de Fabric REST API's aan. Neem elke vervangingsprincipaal op in de toegestane beveiligingsgroep wanneer de instelling groepsgebonden is.
Service-principals kunnen werkruimten, verbindingen en implementatiepijplijnen maken Uitgeschakeld voor nieuwe klanten. De applicatie richt deze bronnen in.
Inhoud insluiten in apps Ingeschakeld in bestaande configuraties; controleer uw tenant. Uw bestaande toepassing sluit content in via de toepasselijke REST API's.
Toestaan dat service-principals profielen maken en gebruiken Ga er niet van uit dat er een standaardwaarde is. Alleen zolang klanten nog steeds de profielroute gebruiken; niet vereist voor gemigreerde klanten.

Controleer de werkelijke waarden in plaats van de standaardwaarden aan te nemen. Nieuwe en bestaande tenants kunnen verschillen en beheerders kunnen instellingen wijzigen. Behoud de profielinstelling totdat elke afhankelijke klant en job wordt gemigreerd. Schakel geen instellingen voor insluiting in voor een workload zonder insluiting.

Stap 1: de door de gebruiker toegewezen beheerde identiteit maken en toewijzen

Deze beheerde identiteit vertegenwoordigt de ISV-toepassing, niet een afzonderlijke klant. Gebruik een bestaande resourcegroep:

az identity create \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --location "<azure-region>"

Noteer de client-id, de principal-id (object), de tenant-id van de directory en Azure resource-id. Wijs het toe aan de computeresource. Voor een bestaande App Service-toepassing:

az webapp identity assign \
  --resource-group "<resource-group>" \
  --name "<web-app-name>" \
  --identities "<managed-identity-resource-id>"

Gebruik de bijbehorende procedure voor identiteitstoewijzing voor andere computeservices. Selecteer expliciet deze door de gebruiker toegewezen identiteit in de runtime. Omdat de identiteit onafhankelijk is van de hostresource, hoeft het opnieuw uitrollen van een host niet elke vertrouwensrelatie van de klant te vervangen.

Stap 2: Een service-principal maken voor elke klant

Maak voor elke klant-, gebruikers- of groepsafbakening die door de bestaande profielen wordt vertegenwoordigd een toepassingsregistratie en de bijbehorende service-principal. In dit voorbeeld wordt een toepassing met één tenant gemaakt in de directory van de ISV:

APP_CLIENT_ID=$(az ad app create \
  --display-name "customer-a-application" \
  --sign-in-audience AzureADMyOrg \
  --query appId --output tsv)

az ad sp create --id "$APP_CLIENT_ID"

APP_OBJECT_ID=$(az ad app show \
  --id "$APP_CLIENT_ID" --query id --output tsv)

SP_OBJECT_ID=$(az ad sp show \
  --id "$APP_CLIENT_ID" --query id --output tsv)
Identificatie Gebruiken
Client-id van de toepassing Identificeer de klanttoepassing bij het aanvragen van een toegangstoken.
Id van toepassingsobject Configureer de gefedereerde referentie op de toepassingsregistratie.
Object-id van de service principal Werkruimte- of resourcerollen verlenen wanneer de API de object-id van de principal vereist.

Note

Referenties voor het aanbevolen pad: Maak geen clientgeheim of -certificaat voor deze authenticatieroute. De federatieve vertrouwensrelatie van de klanttoepassing levert het authenticatiemechanisme.

Stap 3: Federatieve identiteitsgegevens configureren

Haal de principal-id van de beheerde identiteit en de bijbehorende tenant-id van de directory op. Gebruik de tenant van de identiteit in plaats van ervan uit te gaan dat een ander huidig abonnement dezelfde tenant heeft:

MI_PRINCIPAL_ID=$(az identity show \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --query principalId --output tsv)

DIRECTORY_TENANT_ID=$(az identity show \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --query tenantId --output tsv)

Voeg een federatieve identiteitsreferentie toe aan elke registratie van klanttoepassingen. De volgende opdracht voor de globale cloud maakt gebruik van de object-id van de toepassing uit stap 2 en de MI-waarden die zojuist zijn opgehaald:

az ad app federated-credential create \
  --id "$APP_OBJECT_ID" \
  --parameters "{
    \"name\": \"trust-application-mi\",
    \"issuer\": \"https://login.microsoftonline.com/$DIRECTORY_TENANT_ID/v2.0\",
    \"subject\": \"$MI_PRINCIPAL_ID\",
    \"audiences\": [\"api://AzureADTokenExchange\"],
    \"description\": \"Trust the ISV application managed identity\"
  }"

U kunt ook dezelfde JSON opslaan met vervangen waarden in een lokaal credential.json bestand en doorgeven --parameters credential.json. Herhaal het vertrouwen voor elke klanttoepassing. Wacht tot de configuratie is doorgegeven voordat tokenuitwisseling wordt gecontroleerd.

Stap 4: Elke service-principal toegang verlenen tot de werkruimte

Voeg de klantservice-principal alleen toe als lid of beheerder aan de aangewezen werkruimten waarvoor die rol is vereist. Geef de voorkeur aan een lagere ondersteunde rol als deze voldoet aan de vereisten voor de bewerking. Deze machtiging is wat de resourcetoegang van de klant daadwerkelijk bepaalt.

Gebruik de beheerinterface van de werkruimte of de workspace-REST-bewerking voor roltoewijzing. In het volgende voorbeeld worden configureerbare API's en resource-id's gebruikt. Hiervoor is een geautoriseerde provisioningidentiteit vereist; de runtime-MI zelf krijgt geen resourcemachtigingen van de klant voor tokenuitwisseling.

PROFILE_API_BASE="<existing-profile-aware-api-base-url>"
PROFILE_RESOURCE="<existing-api-resource-identifier>"
WORKSPACE_ID="<customer-workspace-id>"

TOKEN=$(az account get-access-token \
  --resource "$PROFILE_RESOURCE" \
  --query accessToken --output tsv)

curl --fail-with-body --request POST \
  "$PROFILE_API_BASE/v1.0/myorg/groups/$WORKSPACE_ID/users" \
  --header "Authorization: Bearer $TOKEN" \
  --header "Content-Type: application/json" \
  --data "{
    \"identifier\": \"$SP_OBJECT_ID\",
    \"groupUserAccessRight\": \"Member\",
    \"principalType\": \"App\"
  }"

Gebruik het eindpunt en de request shape die is gedocumenteerd voor de service die eigenaar is van de bestaande werkruimte. De weergegeven bewerking is van toepassing op de profielbewuste werkruimte-API; andere API's kunnen verschillende schema's voor roltoewijzing gebruiken. Gebruik geen client-id in plaats van een service-principalobject-id wanneer de bewerking die verwacht. Vermijd het loggen van bearer-tokens en sta machtigingsdoorgifte toe.

Stap 5: API's verifiëren en aanroepen tijdens runtime

  1. Los de applicatie-client-ID van de geauthenticeerde klant en toegestane resources op uit de vertrouwde serverconfiguratie.

  2. Haal een assertietoken op met behulp van de geselecteerde door de gebruiker toegewezen beheerde identiteit en het api://AzureADTokenExchange/.default bereik in de globale cloud.

  3. Gebruik het MI-token als client assertion voor de klanttoepassing. Vraag een toegangstoken aan met het toepassingsbereik van de resource-API, niet de assertiedoelgroep.

  4. Roep de target-API aan met behulp van het toegangstoken van de klanttoepassing en zonder profielselectieconfiguratie. Beheer werkruimten, vraag alle vereiste toepassingsspecifieke tokens aan en voer andere geïnventareerde bewerkingen uit via de klantidentiteit.

Gebruik voor .NET Azure Identity ClientAssertionCredential met het token van de beheerde identiteit als assertion callback. Het zesstappenproces en de officiële configuratievoorbeelden tonen de uitwisseling zonder dat hiervoor een voorbeeld van embedding-specifieke toepassingscode is vereist.

Onboarding en offboarding automatiseren

Neem de vier onboardingbewerkingen op in uw inrichtingspijplijn: maak de toepassingsregistratie, maak de service-principal, configureer de federatieve vertrouwensrelatie en wijs de werkruimterol toe. Bouw tegelijkertijd het overeenkomende offboardingpad: verwijder resourcetoekenningen, trek verouderde vertrouwensrelaties of inloggegevens in en verwijder toepassings-id's pas nadat de afhankelijkheden zijn gecontroleerd.

Alternatieve implementatie: service-principals rechtstreeks authenticeren

Als u MI en federatie niet wilt gebruiken, slaat u stap 1 en 3 over. Voltooi stap 2 voor elke klant en configureer een ondersteunde toepassingsaanmelding in plaats van een federatieve vertrouwensrelatie.

Gebruik een certificaat waarvoor ondersteuning wordt geboden en volg de richtlijnen voor het instellen van toepassingsreferenties. Upload het openbare certificaat, beveilig de privésleutel in een geschikte referentieopslag en automatiseer verlenging. Als een clientgeheim nodig is, moet u het beveiligen en vernieuwen voordat het verloopt.

Voer stap 4 uit met dezelfde minst bevoegde klantmachtigingen. Gebruik in stap 5 de client-id van de klant en de bijbehorende inloggegevens om rechtstreeks een toegangstoken voor clientreferenties aan te vragen. Behoud dezelfde klantroutering, scheiding van tokencache, validatie en controles voor opschoning van migratie.

Beveiliging, beperkingen en overwegingen

Pas de volgende maatregelen toe op het verificatiepad dat u selecteert en plan voor de bijbehorende operationele limieten.

Aanbevelingen voor beveiliging

  • Gebruik een stabiele door de gebruiker toegewezen beheerde identiteit. Dit voorkomt dat klantvertrouwensrelaties verloren gaan omdat een rekenresource wordt vervangen. Gebruik geen identiteit die door het systeem is toegewezen als assertiebron voor dit app-vertrouwenspatroon.

  • Behandel de beheerde identiteit (MI) van de toepassing als een identiteit met hoge bevoegdheden. Het kan zich voordoen als elke klanttoepassing die deze vertrouwt. Beperk rechten voor implementatie van rekenresources, toewijzing van beheerde identiteiten, applicatie-eigenaren en beheer van aanmeldingsgegevens. Scheid runtime-identiteiten indien nodig om het bereik van inbreuk te verminderen.

  • Geef de MI geen eigen machtigingen voor de klantendienst. Het is een bron voor assertions; klantenservice-principals ontvangen workspace- en downstreamservicetoekenningen.

  • Beperk tenantinstellingen tot een beveiligingsgroep. Neem de service-principal van elke relevante klant op in de toegestane groep in plaats van toegang tot de service-principal in te schakelen voor de hele organisatie.

  • Bewaak en stel waarschuwingen in voor de aanmeldingen van elke service-principal. Correleer dit met toepassings- en resourcelogboeken. Het verzamelen van logboeken zonder klantspecifiek onderzoek en alarmering levert het operationele voordeel niet op.

  • Automatiseer onboarding en offboarding samen. Het verwijderen van werkruimterollen, het buiten gebruik stellen van referenties of vertrouwensrelaties en het verwijderen van verouderde service-principals moeten net zo gecontroleerd en herhaalbaar zijn als het inrichten ervan.

Behoud klanttoewijzingen aan de serverzijde, valideer het lidmaatschap voordat u een identiteit selecteert en wijs willekeurige door de client geleverde identiteit- of resource-id's af. Token hergebruik betekent dat één aanmeldingsrecord geen record is van elke API-aanroep. Leg geen geheimen, asserties, toegangstokens of privésleutels van certificaten vast.

Beperkingen en operationele vereisten

Consideratie Waar u rekening mee moet houden
Schaalplafond vergeleken met profielen Profielen staan 100.000 per bovenliggende service-principal toe, met maximaal 1000 werkruimten per profiel. Afzonderlijke toepassingsregistraties en service-principals gebruiken mapobjecten. Controleer de directoryquota, de werkruimtelimieten van de service-principal en de inrichtingsdoorvoer voordat u vastlegt.
Limiet voor federatieve aanmeldingsgegevens Een app-registratie ondersteunt maximaal 20 federatieve identiteitsgegevens. Deze architectuur heeft doorgaans voor elke toepassing per klant één beheerde identiteit van de vertrouwde runtime nodig, niet één per klant in een gedeelde toepassing.
Vereiste voor dezelfde tenant De beheerde identiteit en elke vertrouwende toepassingsregistratie moeten behoren tot dezelfde Microsoft Entra-tenant. Voor toegang tot resources in een andere tenant is bovendien een ondersteunde toepassingsconfiguratie, toestemming en resourcemachtigingen vereist.
Geen cross-cloudtokenuitwisseling Wissel geen tokens uit tussen verschillende Azure-clouds, zoals de wereldwijde cloud en US Government. Gebruik de juiste audience- en autoriteitseindpunten in de doelcloud.
Vereiste voor Azure Compute Voor de assertiestroom op basis van beheerde identiteit is het mechanisme voor beheerde identiteit van een ondersteunde Azure-hostingomgeving vereist. Als de app ergens anders wordt uitgevoerd of als u dit patroon niet wilt gebruiken, gebruikt u het alternatief voor directe authenticatie of een andere ondersteunde federatiearchitectuur.
Voorwaardelijke toegang Microsoft Entra Workload-id Premium is vereist om beleid voor voorwaardelijke toegang voor workloadidentiteiten te maken of te wijzigen. Beleidsregels hebben betrekking op in aanmerking komende single-tenant service-principals die eigendom zijn van de organisatie en moeten er rechtstreeks op zijn gericht. Ze hebben geen betrekking op beheerde identiteiten en worden niet louter van kracht via groepslidmaatschap.
Tenantinstellingen voor ontwikkelaars Elke service-principal die gebruikmaakt van een instelling binnen het bereik van een groep, moet zich in de toegestane beveiligingsgroep bevinden. Controleer de vier instellingen in de implementatievereisten; ga niet uit van de standaardinstellingen.
Automation Handmatig beheer van honderden of duizenden klantidentiteiten is onpraktisch. Automatiseer het inrichten, wijzigingen in toekenningen, bewaking, rotatie of vertrouwensupdates en offboarding. Throttling afhandelen met een beperkt aantal nieuwe pogingen en backoff.
Ervaringen alleen voor gemachtigden blijven buiten de reikwijdte Als u profielen vervangt, wordt verificatie met alleen apps niet ingeschakeld wanneer voor een workload gedelegeerde gebruikerstokens zijn vereist. Alleen dat itemtype en gedelegeerde gebruikersauthenticatie worden ondersteund in de preview van het insluiten van Real-Time Dashboard; tokens voor alleen apps en app-owns-data-tokens worden niet ondersteund. Het insluiten van bestaande rapporten maakt gebruik van het toepasselijke servicespecifieke mechanisme.

Raadpleeg Microsoft Entra servicelimieten en de API-identiteitsondersteuning van de doelservice voordat u capaciteit en machtigingen definitief vaststelt.

Zie overwegingen voor federatieve identiteitsreferentie voor huidige vertrouwenslimieten en doorgiftegedrag.

Zie Voorwaardelijke toegang voor workloadidentiteiten voor de huidige geschiktheid van beleid en licenties.

Gebruik waar nodig de global-cloud token-exchange-audience api://AzureADTokenExchange, de doelgroep voor de Amerikaanse overheid api://AzureADTokenExchangeUSGov of de doelgroep voor China api://AzureADTokenExchangeChina. Koppel het authoriteitseindpunt aan de cloud. In de voorbeelden in dit artikel wordt gebruikgemaakt van de global cloud.

Gebruik ondersteunde identiteitsbibliotheken voor tokencaching en tokenvernieuwing. Toestaan dat vertrouwen en machtigingen worden doorgegeven, tijdelijke fouten opnieuw proberen met begrensde back-off en persistente issuer-, subject- of audience-mismatches onderzoeken. Voor directe authenticatie roteert u certificaten en secrets met een overlappingsperiode en controleert u de vervaldatum.

Ga er niet van uit dat het verwijderen van een profiel, het verwijderen van een referentie of het wijzigen van een vertrouwensrelatie onmiddellijk eerder uitgegeven tokens ongeldig maakt. Houd rekening met de levensduur van tokens en het autorisatie- en intrekkingsgedrag van elke resourceservice bij het plannen van cutover en offboarding.

Verwante onderwerpen

Gebruik deze verwijzingen voor API-specifieke machtigingen, huidige identiteitsbeperkingen en bestaande workloadconfiguratie.

Profielen, service-principals en bestaande workloads

Workloadidentiteitsfederatie en beheerde identiteit

SDK’s, API’s en servicelimieten

  • Laatst bijgewerkt om