Erstatt tjenestekontohaverprofiler med tjenestekontohavere

Hvis løsningen bruker tjenestekontohaverprofiler (SPP) og deres identitet, styring, API eller driftsbegrensninger begrenser kravene dine, hjelper denne veiledningen deg med å evaluere og implementere en erstatning basert på dedikerte Microsoft Entra tjenestekontohavere. Hvis den eksisterende profilbaserte løsningen oppfyller kravene dine, kan du fortsette å bruke den.

For kunder som velger å overføre, anbefaler denne veiledningen administrert identitet og legitimasjon i forbund der verts- og klareringskravene oppfylles. Direkte tjenestekontohavergodkjenning er fortsatt et alternativ. Begge banene gir dedikerte kundeidentiteter for katalogstyring, uavhengig påloggingsovervåking og tilgang til støttede tjenester utover profilavhengige grensesnitt.

Hvorfor overføre fra profiler

Vurder å erstatte profiler når følgende begrensninger begrenser løsningen:

• Profiler samsvarer ikke med Microsoft Entra ID anbefalte fremgangsmåter for styrende arbeidsbelastningsidentiteter. En profil har ingen representasjon i Microsoft Entra ID. Den produserer ingen uavhengige påloggingslogger, kan ikke ha sin egen policy for betinget tilgang og kan ikke styres av verktøyet som brukes for resten av identitetseiendommen.

Du kan for eksempel ikke konfigurere en profil som identiteten til en Direct Lake-tilkobling fra en semantisk modell til et lakehouse eller lager. Du kan heller ikke gi den tilgang som en uavhengig Microsoft Entra identitet til andre nedstrømstjenester som programmet eller arbeidsbelastningene må nå. En dedikert tjenestekontohaver kan motta disse tillatelsene der tjenesten støtter den.

Du kan ikke bruke profiler med rest-API-ene Fabric. Profiler støttes bare av den profilbevisste REST-API-en, dens .NET SDK og støttede XMLA/TOM-grensesnitt. REST-API-ene for Fabric støtter ikke profiler, og støtte er ikke planlagt. Bruk en støttet identitet for disse API-kall i stedet for en profil. Oppretting av en dedikert tjenestekontohaver tar for seg identitetskravet, men hver API og operasjon må fortsatt støtte denne identiteten og gi den de nødvendige tillatelsene.

• Godkjenning forblir knyttet til den overordnede identiteten. Når forelderen bruker en hemmelighet eller et sertifikat, beskytter og roterer du denne legitimasjonen. Det anbefalte erstatningsmønsteret unngår lagret kundeprogramlegitimasjon. Profiler kan også bruke en overordnet administrert identitet, slik at hemmelig godkjenning alene ikke krever erstatning av profiler. En overordnet administrert identitet gir ikke profilene uavhengige katalogidentiteter eller bredere API-støtte.

Profiler løser et skalaproblem, ikke et uavhengig identitetsproblem. Én overordnet tjenestekontohaver kan opprette opptil 100 000 profiler, og hver profil kan få tilgang til eller opprette opptil 1000 arbeidsområder. En tjenestekontohaver kan tilhøre maksimalt 1000 arbeidsområder i denne modellen. Dedikerte kundeidentiteter bruker i stedet Microsoft Entra katalogobjekter. Valider gjeldende grenser mot kundeantallet før du forplikter deg til overføringen.

Andre profilbegrensninger å vurdere

Mønsteret for administrert identitet og legitimasjon i forbund

Bruk dette mønsteret for en ny dedikert hovedløsning, eller når du velger å erstatte profiler, forutsatt at kjøretiden oppfyller kravene til administrert identitetsvert.

Mønsteret

Gi hver kunde en ekte Microsoft Entra tjenestekontohaver og bruk programmets administrerte identitet som en deklarasjonskilde. Denne fremgangsmåten erstatter både den delte programlegitimasjonen og profilabstraksjonen. Du kan logge, styre og vurdere hver kundeidentitet for arbeidsbelastningsidentitet betinget tilgang, og den kan kalle støttes Fabric REST-API-er.

Denne fremgangsmåten er den anbefalte overføringsbanen der Azure verts- og klareringskrav passer til løsningen. Den fjerner lagret legitimasjon for kundeprogram og rotasjonsprosesser uten å endre hvor arbeidsområdet og ressursautorisasjonen håndheves.

Arkitekturen viser programmets kjøretidsoperasjoner, tre kundeprogramidentiteter og klareringer og én-til-én-kundearbeidsområderelasjoner. Den representerer standard ordning for delt kjøretid, ikke en ny isolasjonsgrense.

Figur 1. Én programadministrert identitet godkjennes som dedikerte kundeservicekontohavere.

Slik fungerer det

1. Programadministrert identitet. Tilordne en brukertildelt administrert identitet til ISV-programmet som kjører på støttede Azure databehandling, for eksempel App Service, Container Apps, en riktig konfigurert AKS-arbeidsbelastning eller en virtuell maskin. Bruk én administrert identitet for programmet, ikke én per kunde. Den har ingen egne kundearbeidsområde- eller måltjenestetillatelser. dens rolle her er bare å gi en deklarasjon.

2. Tjenestekontohavere per kunde, bruker eller gruppe. Opprett en Microsoft Entra programregistrering og tjenestekontohaver i ISV-katalogleieren for hver eksisterende kunde- eller autorisasjonsgrense. En logisk kunde betyr ikke nødvendigvis en separat Microsoft Entra leier, og en identitet per sluttbruker kreves ikke med mindre den eksisterende tilgangsutformingen krever det.

3. Legitimasjon for organisasjonsbasert identitet. Konfigurer legitimasjon for organisasjonsbasert identitet for hver kundeprogramregistrering for å klarere programmets administrerte identitet. Kjøretiden kan deretter bruke det administrerte identitetstokenet som en deklarasjon for å få et tilgangstoken for dette kundeprogrammet uten en klienthemmelighet eller et sertifikat.

4. Kjøretidstokenutveksling. Når bruker A eller en kundespesifikk jobb aktiverer programmet, kan du løse kunde A gjennom en klarert tilordning på serversiden. Hent det administrerte identitetstokenet med målgruppen api://AzureADTokenExchange, bytte det mot et tilgangstoken som SP-A, og kall deretter mål-API-ene ved hjelp av SP-A-tokenet til å administrere arbeidsområder, utføre ressursoperasjoner eller be om programspesifikke tokener der det er nødvendig.

   For utvekslingen i det foregående trinnet godtar .NET Azure Identity ClientAssertionCredential det administrerte identitetstokenet som en klientdeklarasjon. Dette er en Azure identitetslegitimasjonstype, ikke en MSAL-klasse. Tilgangstokenet må være rettet mot målgruppen for ressurs-API-en, ikke tokenutvekslingsgruppen.

5. Arbeidsområdetilgang. Gi hvert tjenestekontohavermedlem eller administrator tilgang bare til de angitte arbeidsområdene når disse rollene er nødvendige, eller den minst privilegerte rollen som støttes for de nødvendige operasjonene. Dette gir ressurstilgang for omfang. Siden programmets administrerte identitet kan godkjennes som alle kundeprogrammer som klarerer det, kan du behandle det og dets databehandlingsverter som høyverdiidentiteter og infrastruktur.

Hvorfor denne banen anbefales

• Færre langlevde legitimasjoner. Du trenger ikke å lagre, hente eller distribuere noen privatnøkkel for kundeprogram eller sertifikat til kjøretiden.

• Mindre rotasjonsarbeid. Azure administrerer legitimasjonen for administrert identitet og utsteder kortvarige tokener. Du trenger ikke en egen hemmelig eller sertifikatfornyelsesprosess for hvert kundeprogram som bruker denne klareringen.

• Konsekvent pålasting. Klargjør et kundeprogram og en tjenestekontohaver, definer eksplisitt klarering og gi kunderessurstilgang. Nye kunder krever ikke ny langlevd legitimasjon.

Disse fordelene fjerner ikke behovet for klareringsadministrasjon, kundeautorisasjon, overvåking eller planlegging av katalogkapasitet.

Alternativ: Godkjenning av direkte tjenestekontohaver

Hvis du ikke vil bruke administrert identitet og legitimasjon i forbund, oppretter du de samme dedikerte kundeprogramregistreringene og tjenestekontohaverne, men godkjenner dem direkte med sertifikater eller en annen støttet programlegitimasjon. Foretrekker sertifikater fremfor klienthemmeligheter der det støttes. Beskytt private nøkler og hemmeligheter, begrens tilgang til dem og automatiser rotasjon.

Direkte godkjenning beholder katalogsynlighet, per hovedpåloggingslogger og tilgang til støttede API-er. Det krever ikke den administrerte identitetsverten eller klareringsordningen, men den eliminerer ikke lagret kundelegitimasjon.

Nøkkelbegreper

Skille legitimasjonen som etablerer klarering fra tokenene som brukes under kjøring.

Legitimasjon for organisasjonsbasert identitet

Konfigurer en legitimasjon for organisasjonsbasert identitet (FIC) på Microsoft Entra programregistrering som støtter kundeservicekontohaveren. Den definerer en klareringsrelasjon med en tokenutsteder og angir hvilken deklarasjon programmet godtar i stedet for en klienthemmelighet eller et sertifikat.

I denne arkitekturen er målidentiteten kundeprogrammet og tjenestekontohaveren. programadministrert identitet er deklarasjonskilden. Dette er grunnen til at du konfigurerer kundelegitimasjonen for programregistreringen i stedet for på tjenestekontohaverobjektet eller den kildeadministrerte identiteten.

Når programmet presenterer det administrerte identitetstokenet og ber om et tilgangstoken for kundeprogrammet, validerer Microsoft Entra ID deklarasjonen mot den forbundsdelegitimasjonen. Utstederen, emnet og målgruppen må samsvare. Hvis valideringen lykkes, utsteder den et tilgangstoken som representerer målkundeservicekontohaveren for den forespurte ressursen.

Den administrerte identiteten og den klarerte programregistreringen må være i samme Microsoft Entra leier. Ressursgruppen er et eget valg fra deklarasjonsgruppen. For Azure Identity er api://AzureADTokenExchange/.defaultdet globale tokenutvekslingsomfanget for skyen . Mål-API-omfanget er normalt ressursidentifikatoren etterfulgt av /.default.

Tokenutvekslingsflyt: Klientlegitimasjon med en samlet deklarasjon

Denne flyten omfatter tre deltakere og seks trinn. SP-A er kunde A's program- og tjenestekontohaver. Tokenet for forvaltet identitetsdeklarasjon og det returnerte SP-A ressurstilgangstokenet tjener forskjellige formål.

Figur 2. Klientlegitimasjonstokenutveksling støttet av en administrert identitetsdeklarasjon.

1. Be om det administrerte identitetstokenet. Appen på Azure ber om et administrert identitetstoken med målgruppeapi://AzureADTokenExchange.

2. Returner deklarasjonstokenet. Microsoft Entra ID utsteder det administrerte identitetstokenet, som appen mottar gjennom Azure vertsmiljøets administrerte identitetsmekanisme.

3. Send inn forespørselen om kundetoken. Send en forespørsel til endepunktet for katalogleieren /oauth2/v2.0/token med grant_type=client_credentials, client_id=<SP-A-client-id>, client_assertion=<MI-token>og scope=<target-resource>/.default. Den fullstendige OAuth-forespørselen inneholder client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearerogså . Et identitetsbibliotek håndterer denne parameteren.

4. Valider deklarasjonen. Microsoft Entra ID validerer det administrerte identitetstokenet mot den forbundslegitimasjonen på SP-As programregistrering.

5. Returner kundetilgangstokenet. Microsoft Entra ID returnerer et tilgangstoken for SP-A med målressursen som målgruppe.

6. Kall målet REST API-er. Appen sender SP-As tilgangstoken til mål-API-en. Den bruker ikke deklarasjonstokenet som ressursbærertoken og velger ikke en profil.

Arkitektursammenligning

Erstatningskolonnen dekker vanligvis dedikerte tjenestekontohavere. Administrert identitet og forbund er den anbefalte godkjenningsmetoden, men direkte sertifikat eller annen støttet legitimasjonsgodkjenning er også mulig.

Slik leser du denne tabellen: Ingen av arrangementene gir kryptografisk isolering av kunder. Ressurstilskudd gir tilgang, og kjøretiden kan ha indirekte rekkevidde på tvers av kunder. Profiler tilbyr lett identitetsskala. Dedikerte hovedstoler forbedrer katalogstyring, påloggingssynlighet og API-kompatibilitet. Den anbefalte administrerte identitets- og forbundsbanen fjerner også lagret kundeprogramlegitimasjon.

Overføringsbane

Følgende bane erstatter profiler med dedikerte kundeservicekontohavere. Hold overførings- og tilbakerullingsbeslutninger atskilt for hver kunde.

Fra profiler til administrert identitet og legitimasjon i forbund

Bruk følgende overføringsfaser med en liten pilotkohort og en bryter for per kunde-utrulling. Hold profilruten tilgjengelig til valideringen og den avtalte tilbakerullingsperioden er fullført.

Fase 0: Opprette den programadministrerte identiteten

• Opprett den brukertildelte administrerte identiteten for programmet, og tilordne den til databehandlingsressursen. Implementeringsveiledningen viser kommandoene oppretting og tildeling.

• Registrer hovedkontohaveren (objekt)-ID-en. Hver kundeapplikasjons legitimasjon bruker denne verdien som emne. Registrer også klient-ID, katalogleierens ID og Azure ressurs-ID.

Bruk én administrert identitet for programmet, ikke én per kunde. En egen MI for hver kunde er unødvendig i dette mønsteret: kundeidentiteten er tjenestekontohaveren, og MI leverer deklarasjonen. For større distribusjoner eller mindre kompromissomfang partisjonerer du kunder på tvers av et lite antall kjøretidsidentiteter, som alle er klarert av bare det tilordnede delsettet av kundeprogrammer.

Fase 1: Lager

Vis alle eksisterende profiler gjennom API-en for profilbehandling:

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

For hver profil registrerer du:

• Profil-ID og visningsnavn, overordnet tjenestekontohaver og kundetilordning.

• Tilknyttede arbeidsområder og rolletildelinger.

• Tilknyttede semantiske modeller eller datasett, rapporter og andre ressurser.

• Tilkoblinger, legitimasjon for datakilder, eierskapsavhengigheter, bakgrunnsjobber og API-operasjoner som avhenger av profilen.

Før du endrer en kundes konfigurasjon, registrerer du eksisterende arbeidsområderoller, semantisk modelleierskap, tilkoblingsidentiteter, legitimasjonskonfigurasjon og kunde-til-profil-tilordning som kreves for tilbakerulling. Registrer sikre referanser til legitimasjon, ikke hemmelige verdier.

Registrer totalt antall kunder, og sammenlign de nødvendige program- og tjenestekontohaverobjektene med den Microsoft Entra katalogobjektkvoten før du fortsetter. Valider medlemskapsgrensen på 1000 arbeidsområder og eventuelle ressursspesifikke grenser også. Hvis populasjonen overskrider kvoten for én enkelt katalog, kan du planlegge en støttet kvoteøkning eller bevisst administrert utforming av flere kataloger. det løses ikke automatisk av dette mønsteret.

Fase 2: Klargjør nye identiteter

For hver profil eller gruppe med profiler som tilhører samme grense for kundeautorisasjon:

1. Opprett en programregistrering og tjenestekontohaver. Registrer programklient-ID, programobjekt-ID og objekt-ID for tjenestekontohaver separat.

2. Konfigurer legitimasjon for organisasjonsbasert identitet på registreringen av kundeprogrammet som klarerer programmet MI opprettet i fase 0.

3. Gi den nye tjenestekontohaveren tilgang til de samme kundearbeidsområdene og ressursene. Bruk medlem der operasjonene krever det, eller den minst privilegerte rollen som støttes. Gi administrator bare når det er nødvendig.

Behold eksisterende arbeidsområde- og ressurs-ID-er der de støttes. Et arbeidsområdetilskudd overfører ikke automatisk ressurseierskap, tilkoblingsidentiteter eller datakildelegitimasjon. Fullfør de tjenestespesifikke oppdateringene før fullstendig.

Fase 3: Oppdater programkode

• Erstatt profilvalghodet og SDK-profilkonfigurasjonen med administrert identitetsstøttet tokenutveksling for det valgte kundeprogrammet.

• Oppdater kunde-til-identitet-tilordningen i programdatabasen.

Kunde-ID-er er logiske identifikatorer for ISV-kunder, ikke nødvendigvis Microsoft Entra leier-ID-er. Valider den godkjente brukerens kundemedlemskap før du velger en identitet. Hurtigbuffere for nøkkeltoken etter katalogleier, klient-ID og ressurs eller omfang.

• Oppdater programspesifikk tokengenerering for å bruke tilgangstokenet til kundeservicekontohaveren. Hvis løsningen bygger inn rapporter eller annet innhold, kan du oppdatere denne tokengenereringen også. innebygging er en eksisterende arbeidsbelastning som skal overføres, ikke en forutsetning for denne veiledningen.

• Oppdater arbeidsområdebehandling, nedstrømstilkoblinger, klargjøring, planlagte jobber og alle andre inngangspunkter ved hjelp av den gamle profilkonfigurasjonen.

Fase 4: Valider

Kontroller for hver kunde:

• Arbeidsområde og ressurstilgang lykkes gjennom den nye tjenestekontohaveren.

• Forvaltet identitetstokenanskaffelse og forbundstokenutveksling lykkes for det tiltenkte kundeprogrammet.

• Programspesifikke tokener genereres der de brukes, og eksisterende rapporter eller annet innebygd innhold gjengis på riktig måte der det er aktuelt.

• Nye tjenestekontohaverpålogginger vises i Microsoft Entra ID og kan være korrelert med program- og ressursrevisjonslogger.

• Ingen tilgang til flere kunder: En innringer kan ikke velge en annen kundes programidentitet eller ressurs-ID-er.

Før produksjon cutover, dokumenterer og tester du tilbakerullingsprosedyren for en pilotkunde. Inkluder gjenoppretting av semantisk modelleierskap, tilkoblingsidentiteter, legitimasjon for datakilder og tillatelser som er endret under overføringen. Kontroller at den forrige profilen kan utføre de nødvendige operasjonene etter tilbakerulling, inkludert oppdateringskonfigurasjon og parameteroppdateringer.

Bytt kundens programrute bare etter at godkjenningskriteriene er passert. Overvåk feil, ytelse og tillatelser før du utvider utrullingen.

Hvis valideringen mislykkes, stanser du berørte bakgrunnsjobber midlertidig og gjenoppretter den forrige konfigurasjonen ved hjelp av de støttede prosedyrene for hver tjeneste. Hvis du bytter programruten tilbake til profilen alene, kan det hende at du ikke gjenoppretter operasjoner som avhenger av eierskap eller legitimasjon. Når du har gjenopprettet den nødvendige konfigurasjonen, bytter du tilbake til den profilbaserte ruten og kontrollerer ressurstilgang og avhengige operasjoner før du gjenopptar jobber. Behold de opprinnelige profilene og nødvendige tillatelser gjennom hele tilbakerullingsperioden.

Fase 5: Avviklingsprofiler

• Etter tilbakerullingsperioden fjerner du foreldede opprinnelige overordnede og profilarbeidsområdetilskudd, etter å ha bekreftet at de dedikerte kundeservicekontohaverne har den nødvendige tilgangen.

Slett hver overført profil gjennom API-en for profilbehandling:

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

• Du kan eventuelt slette den opprinnelige delte programregistreringen og tjenestekontohaveren hvis ingen kunde, jobb eller ikke-relatert arbeidsbelastning fortsatt bruker dem. Avslutt foreldet legitimasjon og behold overføringstilordninger og overvåkingsposter i henhold til oppbevaringskravene.

Implementeringsveiledning

Denne veiledningen implementerer den anbefalte administrerte identitets- og forbundslegitimasjonsbanen. Alternativet for direkte godkjenning følger den samme identiteten og tillatelsesoppsettet og beskrives etter hovedtrinnene. Azure CLI eksempler bruker Bash-syntaks. Erstatt plassholdere og logg på den tiltenkte katalogen og abonnementet før du kjører dem.

Forutsetninger

• Et Azure abonnement og tillatelser til å opprette og tilordne administrerte identiteter for den anbefalte banen.

• Tillatelser i Microsoft Entra ID til å opprette programregistreringer og tjenestekontohavere og oppdatere programlegitimasjon. Azure ressurstillatelser og katalogtillatelser er separate.

• Et program som driftes på støttede Azure databehandling, for eksempel App Service, Container Apps, en riktig konfigurert AKS-arbeidsbelastning eller en virtuell maskin. Den MI-støttede deklarasjonskilden i dette mønsteret avhenger av den Azure vertskonfigurasjonen.

• Administrative tillatelser for å gi kundearbeidsområde og ressurstilgang, konfigurere nødvendige tjenesteinnstillinger og gi API-tillatelser eller samtykke der måltjenesten krever dem.

• Azure CLI installert og logget på riktig katalogleieren. Bekreft abonnementskonteksten før du oppretter Azure ressurser.

Leierinnstillinger for utviklere

Se gjennom de relevante innstillingene i tjenestens administrasjonsgrensesnitt under leierinnstillinger og utviklerinnstillinger. Tilgang til tjenestekontohaver for omfangstjeneste til en tillatt sikkerhetsgruppe som inneholder kundeservicekontohaverne. Hvis du vil ha nøyaktig etiketter og gjeldende virkemåte, kan du se tenantinnstillinger for utviklere.

For hver innstilling med gruppeomfang som kreves av løsningen, legger du til alle erstatningskundetjenestekontohavere i en tillatt sikkerhetsgruppe før testing eller fullstendig. Tilgang som gis til den opprinnelige overordnede tjenestekontohaveren, godkjenner ikke automatisk erstatningskontohaverne. Innstillingen for offentlig API-tilgang gjelder både for eksisterende profilavhengige REST-API-er og Fabric REST-API-er. Overføring av bare identiteten fjerner ikke denne forutsetningen.

Følgende offentlige API-innstilling bruker en produktnøytral etikett. Administrasjonsgrensesnittet kan inneholde navnet på tjenesten.

Bekreft faktiske verdier i stedet for å anta standardverdier. Nye og eksisterende leiere kan variere, og administratorer kan endre innstillingene. Behold profilinnstillingen til alle avhengige kunder og aktiviteter overføres. Ikke aktiver innebyggingsinnstillinger for en arbeidsmengde som ikke er innebygging.

Trinn 1: Opprette og tilordne den brukertildelte administrerte identiteten

Denne administrerte identiteten representerer ISV-programmet, ikke en individuell kunde. Bruk en eksisterende ressursgruppe:

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

Registrer klient-ID, hovedkontohaver (objekt) ID, leier-ID for katalog og Azure ressurs-ID. Tilordne den til databehandlingsressursen. For et eksisterende App Service-program:

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

Bruk den tilsvarende prosedyren for identitetstilordning for andre databehandlingstjenester. Velg eksplisitt denne brukertilordnede identiteten i kjøretiden. Siden identiteten er uavhengig av vertsressursen, trenger du ikke å distribuere en vert på nytt for å erstatte alle kundeklareringsrelasjoner.

Trinn 2: Opprette en tjenestekontohaver for hver kunde

Opprett en programregistrering og tjenestekontohaver for hver kunde, bruker eller gruppegrense som eksisterende profiler representerer. Dette eksemplet oppretter et program for én leier i ISV-katalogen:

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)

Trinn 3: Konfigurere legitimasjon for organisasjonsbasert identitet

Hent ID-en for den administrerte identitetskontohaveren og den tilhørende leier-ID-en for katalogen. Bruk identitetens leier i stedet for å anta at et annet gjeldende abonnement har samme leier:

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)

Legg til legitimasjon for organisasjonsbasert identitet i hver kundeprogramregistrering. Følgende globale skykommando bruker programobjekt-ID-en fra trinn 2, og MI-verdiene ble nettopp hentet:

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\"
  }"

Du kan også lagre samme JSON med erstattede verdier i en lokal credential.json fil og sende --parameters credential.json. Gjenta klareringen for hvert kundeprogram. Tillat konfigurasjonsoverføring før validering av tokenutveksling.

Trinn 4: Gi hver tjenestekontohaver arbeidsområdetilgang

Legg til kundeservicekontohaveren som medlem eller administrator bare i de angitte arbeidsområdene der denne rollen er nødvendig. Foretrekker en lavere støttet rolle hvis den oppfyller operasjonskravene. Denne tildelingen er det som faktisk omfatter kundens ressurstilgang.

Bruk administrasjonsgrensesnittet for arbeidsområdet eller REST-operasjonen for arbeidsområderolletilordning. Eksemplet nedenfor bruker konfigurerbare API- og ressursidentifikatorer. Det krever en autorisert klargjøringsidentitet. kjøretid mi i seg selv er ikke gitt kunderessurstillatelser for tokenutveksling.

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\"
  }"

Bruk endepunktet og forespørselsfiguren som er dokumentert for tjenesten som eier det eksisterende arbeidsområdet. Den viste operasjonen gjelder for den profilbevisste arbeidsområde-API-en. andre API-er kan bruke forskjellige rolletilordningsskjemaer. Ikke bytt ut en klient-ID der operasjonen forventer en objekt-ID for tjenestekontohaver. Unngå logging av bærertokener og tillat tillatelsesoverføring.

Trinn 5: Godkjenne og kalle API-er ved kjøring

1. Løs den godkjente kundens programklient-ID og tillatte ressurser fra klarert konfigurasjon på serversiden.

2. Hent et deklarasjonstoken ved hjelp av den valgte brukertildelte administrerte identiteten og api://AzureADTokenExchange/.default omfanget i den globale skyen.

3. Bruk MI-tokenet som en klientdeklarasjon for kundeprogrammet. Be om et tilgangstoken med ressurs-API-ens programomfang, ikke deklarasjonsgruppen.

4. Kall mål-API-en ved hjelp av dette tilgangstokenet for kundeprogrammet og uten profilvalgkonfigurasjon. Administrer arbeidsområder, be om nødvendige programspesifikke tokener og utfør andre lageroperasjoner gjennom kundeidentiteten.

For .NET kan du bruke Azure Identity ClientAssertionCredential med det administrerte identitetstokenet som deklarasjonstilbakeringing. Sekstrinnsflyten og de offisielle konfigurasjonseksempler viser utvekslingen uten å kreve et innebyggingsspesifikk programkodeeksempel.

Automatiser pålasting og offboarding

Pakk inn de fire pålastingsoperasjonene i klargjøringsforløpet: Opprett programregistreringen, opprett tjenestekontohaveren, konfigurer dens forbundsklarering og gi arbeidsområderollen. Bygg den samsvarende offboarding banen samtidig: fjern ressurstilskudd, oppheve foreldet klarering eller legitimasjon, og slett programidentiteter bare etter kontroll av avhengigheter.

Alternativ implementering: Godkjenne tjenestekontohavere direkte

Hvis du ikke vil bruke MI og forbund, kan du hoppe over trinn 1 og 3. Fullfør trinn 2 for hver kunde, og konfigurer en støttet programlegitimasjon i stedet for samlet klarering.

Bruk et sertifikat der det støttes, og følg konfigurasjonsveiledningen for programlegitimasjon. Last opp det offentlige sertifikatet, beskytt privatnøkkelen i et passende legitimasjonslager og automatiser fornyelse. Hvis en klienthemmelighet er nødvendig, må du beskytte den og fornye den før utløpsdatoen.

Fullfør trinn 4 med de samme minst privilegerte kundetilskuddene. I trinn 5 bruker du kundeklient-ID-en og legitimasjonen til å be om tilgangstoken for klientlegitimasjon direkte. Behold de samme kontrollene for kunderuting, tokenbufferseparasjon, validering og overføringsopprydding.

Sikkerhet, begrensninger og hensyn

Bruk følgende kontroller på godkjenningsbanen du velger, og planlegg for driftsgrensene.

Sikkerhetsanbefalinger

• Bruk en stabil brukertilordnet administrert identitet. Dette unngår å miste kundeklareringsrelasjoner bare fordi en databehandlingsressurs erstattes. Ikke bruk en systemtilknyttet identitet som deklarasjonskilde for dette app-klareringsmønsteret.

• Behandle program-MI som en svært privilegert identitet. Det kan godkjennes som alle kundeprogrammer som stoler på det. Begrens distribusjonsrettigheter for databehandling, administrert identitetstilordning, programeiere og legitimasjonsadministrasjon. Partisjonskjøringsidentiteter om nødvendig for å redusere kompromissomfang.

• Gi MI ingen egne kundeservicetillatelser. Det er en deklarasjonskilde. kundeservicekontohavere mottar arbeidsområde- og nedstrøms tjenestetilskudd.

• Innstillinger for omfangsleieren med en sikkerhetsgruppe. Inkluder alle relevante kundeservicekontohavere i den tillatte gruppen i stedet for å aktivere tjenestekontohavertilgang for hele organisasjonen.

• Overvåk og varsle hver tjenestekontohavers pålogginger. Korreler med program- og ressurslogger. Innsamling av logger uten kundespesifikk undersøkelse og varsling gir ikke driftsfordelen.

• Automatiser pålasting og avlasting sammen. Fjerning av arbeidsområderoller, tilbaketrekking av legitimasjon eller klareringer og sletting av foreldede tjenestekontohavere må være like kontrollert og gjentagelig som å klargjøre dem.

Behold kundetilordninger på serversiden, valider medlemskap før du velger en identitet, og forkast vilkårlig klientdefinert identitet eller ressurs-ID-er. Gjenbruk av token betyr at én påloggingspost ikke er en post for hvert API-kall. Ikke logg hemmeligheter, deklarasjoner, tilgangstokener eller private sertifikatnøkler.

Begrensninger og driftskrav

Se Microsoft Entra tjenestegrenser og API-identitetsstøtte for måltjenesten før du fullfører kapasitet og tillatelser.

Hvis du vil se gjeldende klareringsgrenser og virkemåte for overføring, kan du se vurderinger av legitimasjon for organisasjonsidentitet.

Hvis du vil ha gjeldende policykvalifisering og lisensiering, kan du se Betinget tilgang for arbeidsbelastningsidentiteter.

Bruk publikummet for global skytokenutveksling api://AzureADTokenExchange, us Government-målgruppen api://AzureADTokenExchangeUSGoveller Kina-målgruppen api://AzureADTokenExchangeChinaetter behov. Samsvar med myndighetens endepunkt med skyen. Eksemplene i denne artikkelen bruker den globale skyen.

Bruk støttede identitetsbiblioteker for hurtigbufring og oppdatering av token. Tillat klarering og tillatelsesoverføring, prøv midlertidige feil på nytt med avgrenset backoff, og undersøk vedvarende utsteder-, emne- eller målgruppekonflikter. For direkte godkjenning roterer du sertifikater og hemmeligheter med en overlappingsperiode og overvåker utløp.

Ikke anta at sletting av en profil, fjerning av legitimasjon eller endring av en klarering umiddelbart ugyldiggjør tidligere utstedte tokener. Konto for tokenlevetid og hver ressurstjenestes virkemåte for autorisasjon og tilbakekalling når du planlegger fullstendig og offboarding.

Relatert innhold

Bruk disse referansene for API-spesifikke tillatelser, gjeldende identitetsbegrensninger og eksisterende arbeidsbelastningskonfigurasjon.

Profiler, tjenestekontohavere og eksisterende arbeidsbelastninger

• Multitenancy med dedikerte tjenestekontohavere
• Tjenestekontohaverprofiler: En valgfri løsning for multitenancy
• Tjenestekontohaverprofiler for programmer for multitenancy
• Konfigurere et eksisterende innholdsprogram til å bruke en tjenestekontohaver
• Leierinnstillinger for utviklere
• Oversikt over eksisterende analyseinnbygging
• Forhåndsvisning av innebygging av delegert bruker Real-Time instrumentbord

Arbeidsbelastningsidentitetsforbund og administrert identitet

• Oversikt over Arbeidsbelastningsidentitetsforbund
• Viktige hensyn og begrensninger for legitimasjon for organisasjonsbasert identitet
• Konfigurere et program til å klarere en administrert identitet
• Administrerte identiteter for Azure ressurser
• Eksempler på konfigurasjon av forbund

SDK-er, API-er og tjenestegrenser

• Azure Identity ClientAssertionCredential for .NET
• Referanse for programspesifikk tokengenerering for eksisterende arbeidsbelastninger for innebygging
• Microsoft Entra tjenestegrenser og begrensninger
• Støttede programidentiteter for Fabric REST-API-er
• Tilkoblingsidentitet og Direct Lake-sikkerhet
• Betinget tilgang for arbeidsbelastningsidentiteter
• Oppgaveoperasjon for arbeidsområde
• API for profilbehandling