Erstat profiler for tjenesteprincipaler med tjenesteprincipaler

Hvis din løsning bruger SPP (Service Principal Profiles) og deres identitet, styring, API eller driftsmæssige begrænsninger begrænser dine krav, hjælper denne vejledning dig med at evaluere og implementere en erstatning baseret på dedikerede Microsoft Entra tjenesteprincipaler. Hvis din eksisterende profilbaserede løsning opfylder dine krav, kan du fortsætte med at bruge den.

For kunder, der vælger at migrere, anbefaler denne vejledning administrerede identitets- og organisationslegitimationsoplysninger, hvor kravene til hosting og tillid er opfyldt. Godkendelse af en direkte tjenesteprincipal er stadig et alternativ. Begge stier giver dedikerede kundeidentiteter til mappestyring, uafhængig logonovervågning og adgang til understøttede tjenester ud over profilorienterede grænseflader.

Hvorfor migrere fra profiler

Overvej at erstatte profiler, når følgende begrænsninger begrænser din løsning:

• Profiler er ikke i overensstemmelse med Microsoft Entra ID bedste praksis for styrelige arbejdsbelastningsidentiteter. En profil har ingen repræsentation i Microsoft Entra ID. Den producerer ingen uafhængige logonlogge, kan ikke bære sin egen politik for betinget adgang og kan ikke styres af det værktøj, der bruges til resten af identitetsboet.

Du kan f.eks. ikke konfigurere en profil som identiteten for en Direct Lake-forbindelse fra en semantisk model til et lakehouse eller et lager. Du kan heller ikke give den adgang som en uafhængig Microsoft Entra identitet til andre downstream-tjenester, som programmet eller dets arbejdsbelastninger skal nå. En dedikeret tjenesteprincipal kan modtage de tilladelser, som tjenesten understøtter.

Du kan ikke bruge profiler med Fabric REST API'er. Profiler understøttes kun af den profilorienterede REST API, dens .NET SDK og understøttede XMLA/TOM-grænseflader. De Fabric REST API'er understøtter ikke profiler, og support er ikke planlagt. Brug en understøttet identitet til disse API-kald i stedet for en profil. Oprettelse af en dedikeret tjenesteprincipal løser identitetskravet, men hver API og handling skal stadig understøtte denne identitet og give den de nødvendige tilladelser.

• Godkendelse forbliver knyttet til den overordnede identitet. Når den overordnede bruger en hemmelighed eller et certifikat, skal du beskytte og rotere disse legitimationsoplysninger. Det anbefalede erstatningsmønster undgår gemte legitimationsoplysninger for kundeprogrammet. Profiler kan også bruge en overordnet administreret identitet, så hemmelighedsløs godkendelse alene ikke kræver erstatning af profiler. En overordnet administreret identitet giver ikke profilerne uafhængige katalogidentiteter eller bredere API-understøttelse.

Profiler løser et skalaproblem, ikke et problem med uafhængig identitet. En overordnet tjenesteprincipal kan oprette op til 100.000 profiler, og hver profil kan få adgang til eller oprette op til 1.000 arbejdsområder. En tjenesteprincipal i sig selv kan højst tilhøre 1.000 arbejdsområder i denne model. Dedikerede kundeidentiteter forbruger i stedet Microsoft Entra katalogobjekter. Valider de relevante grænser i forhold til dit kundeantal, før du forpligter dig til migreringen.

Andre profilbegrænsninger, der skal overvejes

Mønsteret for administrerede legitimationsoplysninger og organisationsnetværksoplysninger

Brug dette mønster til en ny dedikeret hovedløsning, eller når du vælger at erstatte profiler, forudsat at din kørsel opfylder kravene til administreret identitetshosting.

Mønsteret

Giv hver kunde en reel Microsoft Entra tjenesteprincipal, og brug programmets administrerede identitet som en antagelseskilde. Denne fremgangsmåde erstatter både legitimationsoplysningerne for det delte program og profil abstraktionen. Du kan logge, styre og overveje hver kundeidentitet for betinget adgang til arbejdsbelastningsidentitet, og den kan kalde understøttede Fabric REST API'er.

Denne fremgangsmåde er den anbefalede overførselssti, hvor dens Azure hosting- og tillidskrav passer til løsningen. Den fjerner gemte legitimationsoplysninger for kundeprogrammet og deres rotationsprocesser uden at ændre, hvor godkendelse af arbejdsområder og ressourcer gennemtvinges.

Arkitekturen viser programmets kørselshandlinger, tre kundeprogramidentiteter og tillidsforhold og relationer mellem kundearbejdsområder. Den repræsenterer standardarrangementet for delt kørsel og ikke en ny isolationsgrænse.

Figur 1. Én programadministrer identitet godkendes som dedikerede kundeserviceprincipaler.

Sådan fungerer det

1. Programadministrer identitet. Tildel et brugertildelt administreret id til det ISV-program, der kører på understøttede Azure beregning, f.eks. App Service, Container Apps, en korrekt konfigureret AKS-arbejdsbelastning eller en virtuel maskine. Brug én administreret identitet for programmet, ikke én pr. kunde. Det har ingen egne tilladelser til kundearbejdsområdet eller destinationstjenesten. dets rolle her er kun at angive en antagelse.

2. Tjenesteprincipaler pr. kunde, bruger eller gruppe. For hver eksisterende kunde- eller godkendelsesgrænse skal du oprette en Microsoft Entra programregistrering og tjenesteprincipal i ISV'ens kataloglejer. En logisk kunde betyder ikke nødvendigvis en separat Microsoft Entra lejer, og der kræves ikke en identitet pr. slutbruger, medmindre det eksisterende adgangsdesign kræver det.

3. Legitimationsoplysninger for organisationsnetværksidentitet. Konfigurer legitimationsoplysninger for et organisationsnetværksidentitet for hver kundeprogramregistrering for at have tillid til programmets administrerede identitet. Runtime kan derefter bruge sit administrerede identitetstoken som en antagelse til at få et adgangstoken til det pågældende kundeprogram uden en klienthemmelighed eller et certifikat.

4. Udveksling af kørselstoken. Når bruger A eller et kundespecifikt job aktiverer programmet, skal du løse kunde A via en tilknytning på serversiden, der er tillid til. Hent det administrerede identitetstoken med målgruppen api://AzureADTokenExchange. Ombyt det med et adgangstoken som SP-A, og kald derefter destinations-API'erne ved hjælp af SP-A's token for at administrere arbejdsområder, udføre ressourcehandlinger eller anmode om programspecifikke tokens, hvor det er nødvendigt.

   For udvekslingen i det foregående trin accepterer .NET Azure Identity ClientAssertionCredential det administrerede identitetstoken som en klientantagelse. Dette er en Azure identitetslegitimationsoplysninger, ikke en MSAL-klasse. Adgangstokenet skal være målrettet ressource-API'ens målgruppe og ikke målgruppen for tokenudveksling.

5. Adgang til arbejdsområde. Tildel kun hver tjenesteprincipal medlems- eller administratoradgang til de angivne arbejdsområder, når disse roller er nødvendige, eller den mindst privilegerede understøttede rolle for de påkrævede handlinger. Det giver områdeadgang til ressourcer. Da programmets administrerede identitet kan godkendes som alle de kundeprogrammer, der har tillid til det, skal du behandle det og dets beregningsværter som identiteter og infrastruktur af høj værdi.

Hvorfor denne sti anbefales

• Færre legitimationsoplysninger, der har været i lang tid. Du behøver ikke at gemme, hente eller distribuere kundeprogramhemmelighed eller privat nøgle til kørsel.

• Mindre rotationsarbejde. Azure administrerer de administrerede legitimationsoplysninger og problemer med kortvarige tokens. Du behøver ikke en separat proces for hemmelig eller certifikatfornyelse for alle kundeprogrammer, der bruger denne tillid.

• Ensartet onboarding. Klargør et kundeprogram og en tjenesteprincipal, definer den eksplicitte tillid, og tildel kunderessourceadgang. Nye kunder kræver ikke nye langlivede legitimationsoplysninger.

Disse fordele fjerner ikke behovet for tillidsadministration, kundegodkendelse, overvågningsovervågning eller planlægning af katalogkapacitet.

Alternativt: Godkendelse af direkte tjenesteprincipal

Hvis du ikke vil bruge administrerede identitets- og organisationslegitimationsoplysninger, skal du oprette de samme dedikerede kundeprogramregistreringer og tjenesteprincipaler, men godkende dem direkte med certifikater eller andre understøttede legitimationsoplysninger for programmet. Foretrækker certifikater frem for klienthemmeligheder, hvor det understøttes. Beskyt private nøgler og hemmeligheder, begræns adgangen til dem, og automatiser rotation.

Direkte godkendelse bevarer mappesynlighed, logonlogge pr. hoved og adgang til understøttede API'er. Det kræver ikke den administrerede identitetshosting eller tillidsordning, men det eliminerer ikke gemte kundelegitimationsoplysninger.

Nøglebegreber

Skelne mellem de legitimationsoplysninger, der etablerer tillid, fra de tokens, der bruges på kørselstidspunktet.

Legitimationsoplysninger for organisationsnetværksidentitet

Konfigurer et FIC (Organisationsnetværksidentitetslegitimationsoplysninger) på Microsoft Entra programregistrering, der sikkerhedskopieres af kundeserviceprincipalen. Den definerer et tillidsforhold til en tokenudsteder og angiver, hvilken antagelse programmet accepterer i stedet for en klienthemmelighed eller et certifikat.

I denne arkitektur er målidentiteten kundeprogrammet og tjenesteprincipalen. den programadministrerede identitet er antagelseskilden. Det er derfor, du konfigurerer kundelegitimationsoplysninger i programregistreringen i stedet for på objektet for tjenesteprincipalen eller den kildeadministrerede identitet.

Når programmet præsenterer det administrerede identitetstoken og anmoder om et adgangstoken for kundeprogrammet, validerer Microsoft Entra ID antagelsen i forhold til legitimationsoplysningerne i organisationsnetværket. Udstederen, emnet og målgruppen skal stemme overens. Hvis valideringen lykkes, udsteder den et adgangstoken, der repræsenterer destinationsprincipalen for den ønskede ressource.

Den administrerede identitet og den programregistrering, der er tillid til, skal være i samme Microsoft Entra lejer. Ressourcemålgruppen er et separat valg fra antagelsesmålgruppen. For Azure Identity er api://AzureADTokenExchange/.defaultområdet global-cloud-token-exchange ; destinationens API-område er normalt ressource-id'et efterfulgt af /.default.

Tokenudvekslingsflow: Klientlegitimationsoplysninger med en antagelse i organisationsnetværket

Dette flow omfatter tre deltagere og seks trin. SP-A er kunde A's program- og tjenesteprincipal. Tokenet for den administrerede identitetsantagelse og det returnerede SP-A ressourceadgangstoken tjener forskellige formål.

Figur 2. Tokenudveksling for klientlegitimationsoplysninger understøttes af en administreret identitetsantagelse.

1. Anmod om det administrerede identitetstoken. Appen på Azure anmoder om et administreret identitetstoken med målgruppen api://AzureADTokenExchange.

2. Returner antagelsestokenet. Microsoft Entra ID udsteder det administrerede identitetstoken, som appen modtager via det Azure hostingmiljøs administrerede identitetsmekanisme.

3. Send anmodningen om kundetoken. Send en anmodning til mappelejerens /oauth2/v2.0/token slutpunkt med grant_type=client_credentials, client_id=<SP-A-client-id>, client_assertion=<MI-token>og scope=<target-resource>/.default. Den komplette OAuth-anmodning leverer client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearerogså . Et identitetsbibliotek håndterer denne parameter.

4. Valider antagelsen. Microsoft Entra ID validerer det administrerede identitetstoken i forhold til legitimationsoplysningerne i organisationsnetværket i SP-A's programregistrering.

5. Returner kundeadgangstokenet. Microsoft Entra ID returnerer et adgangstoken for SP-A med destinationsressourcen som målgruppe.

6. Kald destinations-REST API'erne. Appen sender SP-A's adgangstoken til destinations-API'en. Det bruger ikke antagelsestokenet som ressourcebærertoken og vælger ikke en profil.

Sammenligning af arkitektur

Erstatningskolonnen dækker generelt dedikerede tjenesteprincipaler. Administreret identitet og samling er den anbefalede godkendelsesmetode, men direkte certifikat eller anden understøttet godkendelse af legitimationsoplysninger er også mulig.

Sådan læser du denne tabel: Ingen af ordningerne giver kunderne kryptografisk isolation. Ressourcetilskuddet gennemtvinger adgang, og kørselstidspunktet kan have indirekte rækkevidde på tværs af kunder. Profiler tilbyder letvægtsidentitetsskala. Dedikerede principaler forbedrer mappestyring, synlighed af logon og API-kompatibilitet. Den anbefalede sti til administreret identitet og sammenslutning fjerner også gemte legitimationsoplysninger for kundeprogrammet.

Overførselssti

Følgende sti erstatter profiler med dedikerede kundeserviceprincipaler. Hold beslutninger om migrering og annullering adskilt for hver kunde.

Fra profiler til administrerede identitets- og organisationslegitimationsoplysninger

Brug følgende migreringsfaser med en lille pilotgruppe og en udrulningskontakt pr. kunde. Hold profilruten tilgængelig, indtil valideringen og den aftalte annulleringsperiode er fuldført.

Fase 0: Opret det programadministrerede id

• Opret det brugertildelt administrerede id for programmet, og tildel det til beregningsressourcen. I implementeringsvejledningen vises kommandoerne til oprettelse og tildeling.

• Registrer dens hoved-id (objekt). Alle kundeprogrammers legitimationsoplysninger i organisationsnetværket bruger denne værdi som emne. Registrer også klient-id'et, mappelejer-id'et og Azure ressource-id.

Brug én administreret identitet for programmet, ikke én pr. kunde. En separat MI for hver kunde er unødvendig i dette mønster: Kundens identitet er tjenesteprincipalen, og MI leverer antagelsen. I forbindelse med større udrulninger eller mindre kompromitterende områder kan du partitionere kunder på tværs af et lille antal kørselsidentiteter, der hver især kun er tillid til af det tildelte undersæt af kundeprogrammer.

Fase 1: Lager

Vis alle eksisterende profiler via API'en til profilstyring:

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

For hver profil skal du poste:

• Profil-id og vist navn, overordnet tjenesteprincipal og kundetilknytning.

• Tilknyttede arbejdsområder og rolletildelinger.

• Tilknyttede semantiske modeller eller datasæt, rapporter og andre ressourcer.

• Forbindelser, legitimationsoplysninger for datakilden, ejerskabsafhængigheder, baggrundsjob og API-handlinger, der afhænger af profilen.

Før du ændrer en kundes konfiguration, skal du registrere de eksisterende arbejdsområderoller, semantisk modelejerskab, forbindelsesidentiteter, konfiguration af legitimationsoplysninger og kunde-til-profil-tilknytning, der er nødvendige for annullering. Registrer sikre referencer til legitimationsoplysninger, ikke hemmelige værdier.

Registrer det samlede kundeantal, og sammenlign de påkrævede program- og tjenesteprincipalobjekter med kvoten for Microsoft Entra mappeobjekt, før du fortsætter. Valider grænsen for medlemskab af 1.000 arbejdsområder og eventuelle ressourcespecifikke grænser. Hvis populationen overskrider kvoten for en enkelt mappe, skal du planlægge en understøttet kvoteforøgelse eller bevidst administreret design med flere mapper. det løses ikke automatisk af dette mønster.

Fase 2: Klargør nye identiteter

For hver profil eller gruppe af profiler, der tilhører den samme kundegodkendelsesgrænse:

1. Opret en programregistrering og en tjenesteprincipal. Registrer programklient-id'et, programobjekt-id'et og objekt-id'et for tjenesteprincipalen separat.

2. Konfigurer legitimationsoplysningerne for et organisationsnetværk for registreringen af kundeprogrammet, der har tillid til det program mi, der blev oprettet i fase 0.

3. Tildel den nye tjenesteprincipal adgang til de samme kundearbejdsområder og -ressourcer. Brug Member, hvor de registrerede handlinger kræver det, eller den rolle, der understøttes mindst. Tildel kun administrator, når det er nødvendigt.

Bevar eksisterende arbejdsområde- og ressource-id'er, uanset hvor det understøttes. Et arbejdsområdetildelt overfører ikke automatisk ressourceejerskab, forbindelsesidentiteter eller legitimationsoplysninger for datakilden. Fuldfør disse tjenestespecifikke opdateringer før cutover.

Fase 3: Opdater programkode

• Erstat konfigurationen af profilvalgheaderen og SDK-profilen med administreret identitetsunderstøttet tokenudveksling for det valgte kundeprogram.

• Opdater kunde-til-identitet-tilknytningen i programdatabasen.

Kunde-id'er er logiske id'er for ISV-kunder, ikke nødvendigvis Microsoft Entra lejer-id'er. Valider den godkendte brugers kundemedlemskab, før du vælger en identitet. Nøgletoken cachelagres efter kataloglejer, klient-id og ressource eller omfang.

• Opdater programspecifik tokenoprettelse for at bruge adgangstokenet for kundeserviceprincipalen. Hvis din løsning integrerer rapporter eller andet indhold, skal du også opdatere denne tokenoprettelse. integrering er en eksisterende arbejdsbelastning, der skal overføres, ikke en forudsætning for denne vejledning.

• Opdater administration af arbejdsområder, downstreamforbindelser, klargøring, planlagte job og alle andre indgangspunkt ved hjælp af den gamle profilkonfiguration.

Fase 4: Valider

Bekræft for hver kunde:

• Adgang til arbejdsområde og ressourcer lykkes via den nye tjenesteprincipal.

• Anskaffelse af administreret identitetstoken og udveksling af token i organisationsnetværk lykkes for det tilsigtede kundeprogram.

• Programspecifikke tokens genereres korrekt, hvor de bruges, og eksisterende rapporter eller andet integreret indhold gengives korrekt, hvor det er relevant.

• Nye tjenesteprincipallogge vises i Microsoft Entra ID og kan korreleres med overvågningslogge for programmer og ressourcer.

• Adgang på tværs af kunder blev nægtet: En kalder kan ikke vælge en anden kundes program-id eller ressource-id'er.

Før produktionsnedskæring skal du dokumentere og teste annulleringsproceduren for en pilotkunde. Inkluder gendannelse af ejerskabet af semantiske modeller, forbindelsesidentiteter, legitimationsoplysninger for datakilden og tilladelser, der ændres under migreringen. Kontrollér, at den forrige profil kan udføre de nødvendige handlinger efter annullering, herunder opdateringskonfiguration og parameteropdateringer.

Skift først kundens programrute, når acceptkriterierne er passeret. Overvåg fejl, ydeevne og tilladelser, før udrulningen udvides.

Hvis valideringen mislykkes, kan du afbryde de berørte baggrundsjob midlertidigt og gendanne den tidligere konfiguration ved hjælp af de understøttede procedurer for hver tjeneste. Hvis du skifter programruten tilbage til profilen alene, gendannes muligvis ikke handlinger, der afhænger af ejerskabet eller legitimationsoplysningerne. Når du har gendannet den påkrævede konfiguration, skal du skifte tilbage til den profilbaserede rute og bekræfte ressourceadgang og afhængige handlinger, før du genoptager job. Bevar de oprindelige profiler og de påkrævede tilladelser i hele annulleringsperioden.

Fase 5: Nedlukningsprofiler

• Efter annulleringsperioden skal du fjerne forældede oprindeligt overordnede arbejdsområder og profilarbejdsområder, når du har bekræftet, at de dedikerede kundeserviceprincipaler har den nødvendige adgang.

Slet hver migrerede profil via API'en til profilstyring:

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

• Du kan også slette den oprindelige delte programregistrering og tjenesteprincipal, hvis ingen kunde, job eller ikke-relateret arbejdsbelastning stadig bruger dem. Træk forældede legitimationsoplysninger tilbage, og bevar migreringstilknytninger og overvågningsposter i henhold til dine opbevaringskrav.

Implementeringsvejledning

Denne vejledning implementerer den anbefalede sti til administrerede identiteter og legitimationsoplysninger, der er medlem af organisationsnetværket. Alternativet til direkte godkendelse følger samme konfiguration af identitet og tilladelse og beskrives efter de primære trin. Azure CLI eksempler bruger Bash-syntaksen. Erstat pladsholdere, og log på den ønskede mappe og det tiltænkte abonnement, før du kører dem.

Forudsætninger

• Et Azure abonnement og tilladelser til at oprette og tildele administrerede identiteter for den anbefalede sti.

• Tilladelser i Microsoft Entra ID til at oprette programregistreringer og tjenesteprincipaler og opdatere legitimationsoplysningerne for programmet. Azure ressourcetilladelser og mappetilladelser er separate.

• Et program, der hostes på understøttede Azure beregning, f.eks. App Service, Container Apps, en korrekt konfigureret AKS-arbejdsbelastning eller en virtuel maskine. Den MI-baserede antagelseskilde i dette mønster afhænger af den Azure hostingkonfiguration.

• Administrative tilladelser til at give kundearbejdsområde- og ressourceadgang, konfigurere påkrævede tjenesteindstillinger og tildele API-tilladelser eller -samtykke, hvor måltjenesten kræver dem.

• Azure CLI installeret og logget på den korrekte kataloglejer. Bekræft abonnementskonteksten, før du opretter Azure ressourcer.

Indstillinger for udviklerlejer

Gennemse de relevante indstillinger i din tjenestes administrationsgrænseflade under lejerindstillinger og udviklerindstillinger. Omfang af tjenesteprincipalens adgang til en tilladt sikkerhedsgruppe, der indeholder kundeserviceprincipalerne. Du kan se de nøjagtige mærkater og den aktuelle funktionsmåde under Indstillinger for udviklerlejer.

For hver gruppeomfangsindstilling, der kræves af din løsning, skal du føje hver erstatningsprincipal for kundeservice til en tilladt sikkerhedsgruppe, før du tester eller går over. Adgang, der er tildelt den oprindelige overordnede tjenesteprincipal, godkender ikke automatisk erstatningsprincipalerne. Adgangsindstillingen for den offentlige API gælder for både de eksisterende profilorienterede REST API'er og de Fabric REST API'er. Hvis du kun overfører identiteten, fjernes denne forudsætning ikke.

Følgende offentlige API-indstilling bruger et produktneutralt navn. administrationsgrænsefladen kan indeholde tjenestens navn.

Kontrollér de faktiske værdier i stedet for at antage standardværdier. Nye og eksisterende lejere kan variere, og administratorer kan ændre indstillingerne. Bevar profilindstillingen, indtil alle afhængige kunder og job migrerer. Aktivér ikke integreringsindstillinger for en arbejdsbelastning, der ikke er integreret.

Trin 1: Opret og tildel den brugertildelt administrerede identitet

Denne administrerede identitet repræsenterer ISV-programmet, ikke en individuel kunde. Brug en eksisterende ressourcegruppe:

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

Registrer klient-id'et, hoved-(objekt)-id'et, mappelejer-id'et og Azure ressource-id. Tildel den til beregningsressourcen. For et eksisterende App Service-program:

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

Brug den tilsvarende procedure for identitetstildeling til andre beregningstjenester. Vælg eksplicit denne brugertildelt identitet i kørselstidspunktet. Da identiteten er uafhængig af værtsressourcen, behøver geninstallation af en vært ikke at erstatte alle kundetillidsforhold.

Trin 2: Opret en tjenesteprincipal for hver kunde

For hver kunde- eller bruger- eller gruppegrænse, som de eksisterende profiler repræsenterer, skal du oprette en programregistrering og dens tjenesteprincipal. I dette eksempel oprettes et program med en enkelt lejer i ISV'ens mappe:

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)

Trin 3: Konfigurer legitimationsoplysninger for organisationsnetværksidentitet

Hent det administrerede id for identitetsprincipalen og dets mappelejer-id. Brug identitetens lejer i stedet for at antage, at et andet aktuelt abonnement har den samme lejer:

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)

Føj legitimationsoplysninger til et organisationsnetværk til hver kundeprogramregistrering. Følgende global-cloud-kommando bruger programobjekt-id'et fra trin 2 og de MI-værdier, der lige er 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å gemme den samme JSON med erstattede værdier i en lokal credential.json fil og overføre --parameters credential.json. Gentag tillidsforholdet for hvert kundeprogram. Tillad konfigurationsoverførsel, før tokenudveksling valideres.

Trin 4: Giv hver tjenesteprincipal adgang til arbejdsområdet

Føj kun kundeserviceprincipalen som medlem eller administrator til de angivne arbejdsområder, hvor denne rolle er påkrævet. Foretrækker en lavere understøttet rolle, hvis den opfylder handlingskravene. Denne tildeling er det, der faktisk omfatter kundens ressourceadgang.

Brug grænsefladen til administration af arbejdsområdet eller REST-handlingen for rolletildeling for arbejdsområdet. I følgende eksempel bruges konfigurerbar API og ressource-id'er. Det kræver en godkendt klargøringsidentitet; selve kørsels-MI tildeles ikke kunderessourcetilladelser til tokenudveksling.

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

Brug det slutpunkt og den anmodningsfigur, der er dokumenteret for den tjeneste, der ejer det eksisterende arbejdsområde. Den viste handling gælder for api'en til det profilorienterede arbejdsområde. andre API'er kan bruge forskellige skemaer for rolletildelinger. Undlad at erstatte et klient-id, hvor handlingen forventer et objekt-id for en tjenesteprincipal. Undgå logføring af ihændehavertokens, og tillad tilladelsesoverførsel.

Trin 5: Godkend og kald API'er på kørselstidspunktet

1. Løs den godkendte kundes programklient-id og tilladte ressourcer fra serverkonfigurationen, der er tillid til.

2. Hent et antagelsestoken ved hjælp af den valgte brugertildelt administrerede identitet og api://AzureADTokenExchange/.default omfanget i det globale cloudmiljø.

3. Brug MI-tokenet som en klientantagelse for kundeprogrammet. Anmod om et adgangstoken med ressource-API'ens programområde, ikke antagelsesmålgruppen.

4. Kald destinations-API'en ved hjælp af det pågældende adgangstoken til kundeprogrammet og uden konfiguration af profilvalg. Administrer arbejdsområder, anmod om eventuelle påkrævede programspecifikke tokens, og udfør andre handlinger, der er opfundet, via kundeidentiteten.

I forbindelse med .NET skal du bruge Azure Identity ClientAssertionCredential med det administrerede identitetstoken som tilbagekald af antagelse. Det sekstrinsflow og de officielle konfigurationseksempler viser udvekslingen uden at kræve et integreringsspecifikt programkodeeksempel.

Automatiser onboarding og offboarding

Ombryd de fire onboardinghandlinger i din klargøringspipeline: Opret programregistreringen, opret dens tjenesteprincipal, konfigurer dens tillid i organisationsnetværket, og tildel arbejdsområderollen. Opret den tilsvarende offboarding-sti på samme tid: fjern ressourcetilskuddene, tilbagekald forældet tillid eller legitimationsoplysninger, og slet kun programidentiteter, når du har kontrolleret afhængigheder.

Alternativ implementering: Godkend tjenesteprincipaler direkte

Hvis du ikke vil bruge MI og federation, skal du springe trin 1 og 3 over. Fuldfør trin 2 for hver kunde, og konfigurer en understøttet programlegitimationsoplysninger i stedet for tillid i organisationsnetværket.

Brug et certifikat, hvor det understøttes, og følg vejledningen til konfiguration af legitimationsoplysninger for programmet. Upload det offentlige certifikat, beskyt den private nøgle i et passende lager med legitimationsoplysninger, og automatiser fornyelse. Hvis en klienthemmelighed er nødvendig, skal du beskytte den og forny den inden udløb.

Fuldfør trin 4 med de samme mindst privilegerede kundetilskud. I trin 5 skal du bruge kundeklient-id'et og dets legitimationsoplysninger til at anmode om et adgangstoken til klientlegitimationsoplysninger direkte. Bevar de samme kontrolelementer til kunderouting, tokencacheadskillelse, validering og overførselsoprydning.

Sikkerhed, begrænsninger og overvejelser

Anvend følgende kontrolelementer på den godkendelsessti, du vælger, og planlæg dens driftsgrænser.

Sikkerhedsanbefalinger

• Brug en stabil brugertildelt administreret identitet. Derved undgår du at miste kundetillidsforhold, blot fordi en beregningsressource erstattes. Brug ikke en systemtildelt identitet som antagelseskilde for dette mønster for tillid til appen.

• Behandl program-MI som en yderst privilegeret identitet. Den kan godkende som alle de kundeprogrammer, der har tillid til det. Begræns rettigheder til udrulning af beregning, tildeling af administreret identitet, programejere og administration af legitimationsoplysninger. Partitionskørselsidentiteter, hvis det er nødvendigt for at reducere kompromitteret omfang.

• Giv mi'en ingen egne kundeservicetilladelser. Det er en antagelseskilde. kundeserviceprincipaler modtager tilskud til arbejdsområder og downstream-tjenester.

• Områdelejerindstillinger med en sikkerhedsgruppe. Medtag alle relevante kundeserviceprincipaler i den tilladte gruppe i stedet for at aktivere adgang til tjenesteprincipalen for hele organisationen.

• Overvåg og giv besked om hver tjenesteprincipals logon. Korreler med program- og ressourcelogge. Indsamling af logge uden kundespecifik undersøgelse og besked giver ikke den driftsmæssige fordel.

• Automatiser onboarding og offboarding sammen. Fjernelse af arbejdsområderoller, udtrædelse af legitimationsoplysninger eller tillidsforhold og sletning af forældede tjenesteprincipaler skal være lige så kontrolleret og gentagelig som klargøring af dem.

Bevar kundetilknytninger på serversiden, valider medlemskab, før du vælger en identitet, og afvis vilkårlige identitets- eller ressource-id'er, der er angivet af klienten. Genbrug af token betyder, at én logonpost ikke er en post for hvert API-kald. Logfør ikke hemmeligheder, påstande, adgangstokens eller private nøglecertifikater.

Begrænsninger og driftskrav

Se Microsoft Entra tjenestegrænser og destinationstjenestens API-identitetssupport, før du afslutter kapacitet og tilladelser.

Du kan se de aktuelle tillidsgrænser og funktionsmåden for overførsel under Overvejelser i forbindelse med legitimationsoplysninger i organisationsnetværket.

Du kan se den aktuelle politiks berettigelse og licenser under Betinget adgang for arbejdsbelastningsidentiteter.

Brug målgruppen for global-cloud-tokenudveksling api://AzureADTokenExchange, us government-målgruppen api://AzureADTokenExchangeUSGoveller den kinesiske målgruppe api://AzureADTokenExchangeChinaefter behov. Match autoritetens slutpunkt til cloudmiljøet. Eksemplerne i denne artikel bruger det globale cloudmiljø.

Brug understøttede identitetsbiblioteker til cachelagring og opdatering af token. Tillad overførsel af tillid og tilladelse, forsøg midlertidige fejl igen med afgrænset backoff, og undersøg vedvarende uoverensstemmelser mellem udsteder, emne eller målgruppe. Hvis du vil have direkte godkendelse, skal du rotere certifikater og hemmeligheder med en overlapningsperiode og overvåge udløb.

Antag ikke, at sletning af en profil, fjernelse af legitimationsoplysninger eller ændring af et tillidsforhold øjeblikkeligt ugyldiggør tidligere udstedte tokens. Konto for tokenlevetid og hver ressourcetjenestes godkendelses- og tilbagekaldelsesfunktion ved planlægning af cutover og offboarding.

Relateret indhold

Brug disse referencer til API-specifikke tilladelser, aktuelle identitetsbegrænsninger og eksisterende konfiguration af arbejdsbelastninger.

Profiler, tjenesteprincipaler og eksisterende arbejdsbelastninger

• Multitenancy med dedikerede tjenesteprincipaler
• Profiler for tjenesteprincipaler: En valgfri multitenancy-løsning
• Tjenesteprincipalprofiler til programmer med flere lejere
• Konfigurer et eksisterende indholdsprogram til at bruge en tjenesteprincipal
• Indstillinger for udviklerlejer
• Oversigt over integrering af eksisterende analyser
• Eksempel på integrering af dashboards Real-Time delegeret bruger

Samling af arbejdsbelastningsidentiteter og administreret identitet

• Oversigt over organisationsnetværk for arbejdsbelastningsidentitet
• Vigtige overvejelser og begrænsninger for legitimationsoplysninger i organisationsnetværket
• Konfigurer et program til at have tillid til en administreret identitet
• Administrerede identiteter for Azure ressourcer
• Eksempler på organisationskonfiguration

SDK'er, API'er og tjenestegrænser

• Azure Identity ClientAssertionCredential for .NET
• Programspecifik reference til generering af tokens for eksisterende integreringsarbejdsbelastninger
• Microsoft Entra tjenestegrænser og -begrænsninger
• Understøttede programidentiteter for Fabric REST API'er
• Forbindelsesidentitet og Direct Lake-sikkerhed
• Betinget adgang til arbejdsbelastningsidentiteter
• Handling for rolletildeling for arbejdsområde
• API til profilstyring