Hizmet aslı profillerini hizmet asıllarıyla değiştirme

Çözümünüz hizmet sorumlusu profillerini (SPP) ve bunların kimliklerini, idaresini, API'sini veya operasyonel sınırlamalarını kullanıyorsa, bu kılavuz özel Microsoft Entra hizmet sorumlularını temel alan yerine geçecek bir çözümü değerlendirmenize ve uygulamanıza yardımcı olur. Mevcut profil tabanlı çözümünüz gereksinimlerinizi karşılıyorsa, kullanmaya devam edebilirsiniz.

Geçişi seçen müşteriler için bu kılavuz, barındırma ve güven gereksinimleri karşılandığında yönetilen kimlik ve federasyon kimlik bilgilerini önerir. Doğrudan servis sorumlusu kimlik doğrulaması alternatif olarak kalır. Her iki yol da dizin yönetişimi, bağımsız oturum açma izleme ve profil duyarlı arabirimlerin ötesinde desteklenen hizmetlere erişim için ayrılmış müşteri kimlikleri sağlar.

Not

Yeni bir uygulama oluşturuyorsanız adanmış hizmet sorumlularıyla çok kiracılı yapı ile başlayın, ardından kimlik deseni ve uygulama kılavuzunu izleyin. Profil envanteri ve devreden çıkarma aşamaları yalnızca mevcut profil tabanlı uygulamalar için geçerlidir.

Neden profillerden geçiş yapmalısınız?

Aşağıdaki sınırlamalar çözümünüzü kısıtladığında profilleri değiştirmeyi göz önünde bulundurun:

Profiller, yönetişime uygun iş yükü kimlikleri için Microsoft Entra ID en iyi uygulamalarına uygun değildir. Profilin Microsoft Entra ID'de temsili yoktur. Bağımsız oturum açma günlüğü oluşturmaz, kendi Koşullu Erişim ilkesini taşıyamaz ve kimlik varlığının geri kalanı için kullanılan araçlar tarafından yönetilmez.

Örneğin, bir profili anlamsal modelden göl evine veya ambara olan Direct Lake bağlantısının kimliği olarak yapılandıramazsınız. Uygulamanın veya iş yüklerinin erişmesi gereken diğer aşağı akış hizmetlerine, ona bağımsız bir Microsoft Entra kimliği olarak erişim izni de veremezsiniz. Özel bir hizmet sorumlusu, hizmetin desteklediği durumlarda bu izinleri alabilir.

Fabric REST API'leriyle profilleri kullanamazsınız. Profiller yalnızca profil farkındalıklı REST API, .NET SDK'sı ve desteklenen XMLA/TOM arabirimleri tarafından desteklenir. Fabric REST API'leri profilleri desteklemez ve desteklenmesi planlanmamaktadır. Profil yerine bu API çağrıları için desteklenen bir kimlik kullanın. Ayrılmış bir hizmet asıl sorumlusu oluşturmak kimlik gereksinimini karşılar, ancak her API ve işlem yine de bu kimliği desteklemeli ve ona gerekli izinleri vermelidir.

Kimlik doğrulaması ana kimliğe bağlı kalır. Üst öğe bir gizli anahtar veya sertifika kullandığında, bu kimlik bilgilerini koruyun ve yenileyin. Önerilen değiştirme düzeni, depolanan müşteri uygulaması kimlik bilgilerinden kaçınır. Profiller yönetilen kimlik üst öğesini de kullanabilir, bu nedenle tek başına gizli olmayan kimlik doğrulaması için profillerin değiştirilmesi gerekmez. Yönetilen kimlik üst öğesi, profillere bağımsız dizin kimlikleri veya daha geniş API desteği vermez.

Profiller bağımsız kimlik sorununu değil ölçek sorununu çözer. Bir üst hizmet asıl sorumlusu en fazla 100.000 profil oluşturabilir ve her profil en fazla 1.000 çalışma alanına erişebilir veya oluşturabilir. hizmet sorumlusu bu modeldeki en fazla 1.000 çalışma alanına ait olabilir. Bunun yerine ayrılmış müşteri kimlikleri Microsoft Entra dizin nesnelerini tüketir. Geçiş işlemini gerçekleştirmeden önce müşteri sayınız için geçerli sınırları doğrulayın.

Not

Güvenlik sınırı: Profil, kriptografik müşteri sınırı değildir: üst hizmet asıl sorumlusu, profillerinden herhangi biri aracılığıyla işlem yapabilir. Önerilen desen aynı şekilde çalışma zamanı yönetilen kimliğinin, ona güvenen herhangi bir müşteri uygulamasına kimlik doğrulaması yapmasını sağlar. Çalışma alanı ve kaynak izinleri, uygulanan yetkilendirme sınırı olarak kalır. Her iki modelde de çalışma zamanını ve müşteriden kimliğe eşlemeyi koruyun.

Dikkate alınması gereken diğer profil sınırlamaları

Sınırlama	Geçiş sonucu
Bağımsız denetim veya politika kimliği yok	Profilin bağımsız Microsoft Entra oturum açma kaydı veya iş yükü kimliği Koşullu Erişim hedefi yoktur. Adanmış hizmet asılları, ilke uygunluğuna ve lisanslamaya bağlı olarak bu yetenekleri sağlar.
Profil ile ana öğe arasında kalıcı bağlantı	Profiller başka bir üst hizmet sorumlu nesnesine aktarılamaz. Üst öğeyi değiştirmek için yeni profiller, yeni çalışma alanı izinleri ve güncelleştirilmiş müşteri eşlemeleri gerekir.
Kimlik yönetimi portalı yok	Profiller yalnızca API üzerinden kullanılabilir ve Microsoft Entra yönetim araçlarında gösterilmez. Ayrılmış uygulamaların ve hizmet sorumlularının dizin görünürlüğü ve yönetim arabirimleri vardır.

Yönetilen kimlik ve federasyon kimlik bilgileri deseni

Çalışma zamanınızın yönetilen kimlik barındırma gereksinimlerini karşılaması koşuluyla, yeni bir adanmış sorumlu çözümü için veya profilleri değiştirmeyi seçtiğinizde bu düzeni kullanın.

Şablon

Her müşteriye gerçek bir Microsoft Entra hizmet sorumlusu nesnesi verin ve uygulamanın yönetilen kimliğini doğrulama beyanı kaynağı olarak kullanın. Bu yaklaşım hem paylaşılan uygulama kimlik bilgilerinin hem de profil soyutlamasının yerini alır. İş yükü kimliği Koşullu Erişim için her müşteri kimliğini günlüğe kaydedebilir, yönetebilir ve değerlendirebilir ve desteklenen Fabric REST API'lerini çağırabilir.

Bu yaklaşım, Azure barındırma ve güven gereksinimleri buna uygunsa önerilen geçiş yoludur. Çalışma alanı ve kaynak yetkilendirmenin zorunlu tutulduğu yeri değiştirmeden depolanan müşteri uygulaması kimlik bilgilerini ve bunların rotasyon süreçlerini kaldırır.

Mimaride uygulamanın çalışma zamanı işlemleri, üç müşteri uygulaması kimliği ve güven ilişkisi ve bire bir müşteri çalışma alanı ilişkileri gösterilir. Yeni bir yalıtım sınırını değil, varsayılan paylaşılan çalışma zamanı düzenlemesini temsil eder.

Yönetilen kimlik belirteci alan, bunu seçilen bir müşteri uygulama belirteciyle değiştiren ve hedef API'leri çağıran bir ISV uygulamasını gösteren diyagram. Ayrı müşteri A, B ve C servis asılları, uygulamanın yönetilen kimliğine federasyon güveni duyar ve yalnızca ilgili müşteri çalışma alanlarına erişebilir.

Şekil 1. Bir uygulama tarafından yönetilen kimlik, müşteriye adanmış hizmet sorumluları olarak kimlik doğrulaması yapar.

Nasıl çalışır?

Uygulama tarafından yönetilen kimlik. App Service, Container Apps, uygun şekilde yapılandırılmış AKS iş yükü veya sanal makine gibi desteklenen Azure işlem hizmetleri üzerinde çalışan ISV uygulamasına kullanıcı tarafından atanan yönetilen kimlik atayın. Uygulama için tek bir yönetilen kimlik kullanın, müşteri başına bir tane değil. Kendi müşteri çalışma alanı veya hedef hizmeti izinleri yoktur; buradaki rolü yalnızca bir beyan sağlamaktır.
Müşteri, kullanıcı veya grup başına hizmet sorumluları. Mevcut her müşteri veya yetkilendirme sınırı için ISV'nin dizin kiracısında bir Microsoft Entra uygulama kaydı ve hizmet sorumlusu oluşturun. Mantıksal müşterinin ayrı bir Microsoft Entra kiracısı olması gerekmez ve mevcut erişim tasarımı bunu gerektirmediği sürece son kullanıcı başına kimlik gerekmez.
Federasyon kimlik bilgisi. Uygulamanın yönetilen kimliğine güvenmek için her müşteri uygulaması kaydında bir federe kimlik bilgisini yapılandırın. Çalışma zamanı daha sonra yönetilen kimlik belirtecini iddia beyanı olarak kullanarak istemci sırrı veya sertifikası olmadan bu müşteri uygulaması için erişim belirteci alabilir.
Çalışma zamanı token değişimi. A kullanıcısı veya müşteriye özgü bir görev uygulamayı çağırdığında, müşteri A'yı güvenilir bir sunucu tarafı eşlemesi aracılığıyla çözümleyin. Yönetilen kimlik belirtecini hedef kitleyle api://AzureADTokenExchange alın; onu SP-A olarak bir erişim belirteciyle değiş tokuş edin; ardından çalışma alanlarını yönetmek, kaynak işlemleri gerçekleştirmek veya gerektiğinde uygulamaya özgü belirteçler istemek için SP-A'nın belirtecini kullanarak hedef API'leri çağırın.

Önceki adımdaki değişim için .NET Azure Identity ClientAssertionCredential, yönetilen kimlik belirtecini istemci beyanı olarak kabul eder. Bu, bir Azure Kimlik kimlik bilgisi türüdür, MSAL sınıfı değil. Erişim belirteci, belirteç değişimi hedef kitlesini değil kaynak API'sinin hedef kitlesini hedeflemelidir.
Çalışma alanı erişimi. Her hizmet sorumlusu kimliğine, yalnızca bu roller gerektiğinde, belirlenen çalışma alanlarına Member veya Admin erişimi ya da gerekli işlemler için desteklenen en az ayrıcalıklı rolü verin. Bu yetki, kaynak erişiminin kapsamını belirler. Uygulamanın yönetilen kimliği, ona güvenen her müşteri uygulaması kimliğiyle kimlik doğrulayabildiğinden, uygulamayı ve işlem konaklarını yüksek değerli kimlikler ve altyapı olarak değerlendirin.

Bu yol neden önerilir?

Daha az uzun ömürlü kimlik bilgileri. Herhangi bir müşteri uygulama gizli anahtarını veya sertifika özel anahtarını çalışma zamanına depolamanız, erişmeniz veya dağıtmanız gerekmez.
Daha az döndürme işi. Azure yönetilen kimlik kimlik bilgilerini yönetir ve kısa süreli belirteçler oluşturur. Bu güveni kullanan her müşteri uygulaması için ayrı bir gizli anahtara veya sertifika yenileme işlemine ihtiyacınız yoktur.
Tutarlı başlangıç süreci. Bir müşteri uygulaması ve service principal oluşturun, açık güveni tanımlayın ve müşteri kaynağına erişim izni verin. Yeni müşteriler yeni uzun ömürlü kimlik bilgileri gerektirmez.

Bu avantajlar güven ilişkisi yönetimi, müşteri yetkilendirmesi, denetim izleme veya dizin kapasitesi planlaması gereksinimini ortadan kaldırmaz.

Alternatif: Doğrudan service principal kimlik doğrulaması

Yönetilen kimlik ve federasyon kimlik bilgilerini kullanmak istemiyorsanız, aynı ayrılmış müşteri uygulaması kayıtlarını ve hizmet asıllarını oluşturun, ancak bunlarla doğrudan sertifikalar veya desteklenen başka bir uygulama kimlik bilgisi kullanarak kimlik doğrulaması yapın. Destekleniyorsa, istemci gizli dizileri yerine sertifikaları tercih edin. Özel anahtarları ve gizli bilgileri koruyun, bunlara erişimi kısıtlayın ve rotasyonu otomatikleştirin.

Doğrudan kimlik doğrulaması dizin görünürlüğünü, her asıl için oturum açma günlüklerini ve desteklenen API'lere erişimi korur. Yönetilen kimlik barındırma ya da güven ilişkisi gerektirmez, ancak depolanan müşteri kimlik bilgilerini ortadan kaldırmaz.

Kilit kavramlar

Güven oluşturan kimlik bilgilerini çalışma zamanında kullanılan belirteçlerden ayırt edin.

Federatif kimlik bilgileri

Müşteri hizmet sorumlusunu destekleyen Microsoft Entra uygulama kaydında federasyon kimliği kimlik bilgilerini (FIC) yapılandırın. Belirteç veren ile bir güven ilişkisi tanımlar ve uygulamanın istemci gizli anahtarı veya sertifika yerine hangi bildirimi kabul ettiğini belirtir.

Bu mimaride hedef kimlik, müşteri uygulaması ve service principal'dır; uygulamanın yönetilen kimliği onaylama beyanı kaynağıdır. Bu yüzden, hizmet sorumlusu nesnesi veya kaynak yönetilen kimliği yerine uygulama kaydında müşteri kimlik bilgilerini yapılandırırsınız.

Not

Yapılandırma ayrımı: Federe kimlik kimlik bilgileri, diğer federasyon senaryolarında kullanıcı tarafından atanan yönetilen kimliklerde de desteklenir. Bu, buradaki örüntüyü değiştirmez: her müşteri uygulaması kaydında güveni yapılandırın. Bu kılavuzda açıklanan app-trust deseninde, yönetilen kimlik assertion kaynağı olarak yalnızca kullanıcı tarafından atanan yönetilen kimlik desteklenir.

Güvenilir alan	Küresel buluttaki değer
Issuer	`https://login.microsoftonline.com/{directory-tenant-id}/v2.0`
Subject	Kullanıcı tarafından atanan yönetilen kimliğin asıl (nesne) kimliği. İstemci kimliğini kullanmayın.
Seyirci	`api://AzureADTokenExchange`

Uygulama yönetilen kimlik belirtecini sunduğunda ve müşteri uygulaması için bir erişim belirteci istediğinde, Microsoft Entra ID assertion’ı federasyon kimlik bilgisine göre doğrular. Düzenleyen, konu ve hedef kitle eşleşmelidir. Doğrulama başarılı olursa, istenen kaynak için hedef müşteri hizmeti sorumlusunu temsil eden bir erişim belirteci verir.

Yönetilen kimlik ve güvenen uygulama kaydı aynı Microsoft Entra tenant’ında olmalıdır. Kaynak hedef kitlesi, assertion hedef kitlesinden ayrı bir seçimdir. Azure Kimliği için genel bulut belirteci değişim kapsamı api://AzureADTokenExchange/.default değeridir; hedef API kapsamı normalde kaynak tanımlayıcısını ve ardından /.default ifadesini içerir.

Belirteç değişim akışı: Federe beyanı ile istemci kimlik bilgileri

Bu akış üç katılımcı ve altı adımdan oluşur. SP-A, müşteri A'nın uygulaması ve hizmet sorumlusudur. Yönetilen kimlik onay belirteci ve döndürülen SP-A kaynak erişim belirteci farklı amaçlara hizmet eder.

Yönetilen kimlik belirteci isteyen ve alan bir Azure uygulamasını gösteren sıralı diyagram; SP-A'nın istemci kimliği ve iddia olarak yönetilen kimlik belirteciyle bir istemci kimlik bilgileri isteği gönderilmesini, Microsoft Entra ID'nin federasyon güvenini doğrulamasını, SP-A'nın erişim belirtecini döndürmesini ve uygulamanın hedef API'yi SP-A olarak çağırmasını gösterir.

Şekil 2. Yönetilen kimlik onayı ile desteklenen istemci kimlik bilgileri belirteci değişimi.

Yönetilen kimlik belirtecini isteyin. Azure üzerindeki uygulama, api://AzureADTokenExchange hedef kitlesi için bir yönetilen kimlik belirteci istiyor.
Onay belirtecini döndürün. Microsoft Entra ID, uygulamanın Azure barındırma ortamının yönetilen kimlik mekanizması aracılığıyla aldığı yönetilen kimlik belirtecini verir.
Müşteri belirteci isteğini gönderin. client_assertion=<MI-token>, scope=<target-resource>/.default, grant_type=client_credentials ve /oauth2/v2.0/token ile dizin kiracısının client_id=<SP-A-client-id> uç noktasına bir istek gönderin. OAuth isteğinin tamamı client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer parametresini de içerir; kimlik kitaplığı bu parametreyi işler.
Assertion'ı doğrulayın. Microsoft Entra ID, yönetilen kimlik belirtecini SP-A'nın uygulama kaydındaki federasyon kimlik bilgisi ile karşı doğrular.
Müşteri erişim jetonunu iade edin. Microsoft Entra ID, hedef kaynak olacak şekilde SP-A için bir erişim belirteci döndürür.
Hedef REST API'lerini çağırın. Uygulama, SP-A'nın erişim belirtecini hedef API'ye gönderir. Onay belirtecini kaynak taşıyıcı belirteci olarak kullanmaz ve bir profil seçmez.

Mimari karşılaştırması

Değiştirme sütunu genellikle adanmış hizmet asıllarını kapsar. Yönetilen kimlik ve federasyon önerilen kimlik doğrulama yöntemidir, ancak doğrudan sertifika veya desteklenen diğer kimlik bilgileriyle kimlik doğrulama da mümkündür.

Aspect	Service Principal profilleri	Atanmış service principal'ları
Müşteri başına kimlik sayısı	Mantıksal profil, Microsoft Entra nesnesi değil.	Müşteri yetkilendirme sınırını temsil eden uygulama kaydı ve hizmet sorumlusu/uygulama sorumlusu nesnesi.
Zorunlu sınır	Çalışma alanı ve kaynak izinleri.	Çalışma alanı ve kaynak izinleri.
Kök kimlik kapsamı	Ana service principal, profillerinden herhangi biri olarak davranabilir.	Çalışma zamanı, kimlik bilgilerine veya güvenilir beyanlara sahip olduğu tüm kimliklere erişebilir; bir MI, ona güvenen herhangi bir uygulama olarak kimlik doğrulaması yapabilir.
Gizli döndürme işlemi	Üst öğe bir gizli anahtar veya sertifika kullandığında gereklidir.	Yönetilen kimlik kimlik bilgileri için gerekli değildir; doğrudan yolda depolanan sertifikalar veya istemci gizli anahtarları için gereklidir.
Tavan ölçeği	Üst SP başına en fazla 100.000 profil; her profil için en fazla 1.000 çalışma alanı. Üst SP'nin kendi üyeliği 1.000 çalışma alanı ile sınırlıdır.	Müşteri başına bir uygulama kaydı ve hizmet sorumlusu, dizin nesnesi kotalarına ve her hedef hizmetin kaynak sınırlarına tabidir.
Denetim izi	Profil kimlikleri kaynak günlüklerinde görünebilir, ancak profillerin bağımsız Microsoft Entra oturum açma kaydı yoktur.	Uygulama ve kaynak denetim günlükleriyle ilişkilendirilmiş, hizmet sorumlusu başına Microsoft Entra oturum açma kayıtları
Koşullu Erişim	Profil başına workload identity ilkesi yoktur.	Microsoft Entra İş Yükü Kimliği Premium ile uygun hizmet sorumluları için kullanılabilir; ilke her hizmet sorumlusunu doğrudan hedeflemelidir.
Portal görünürlüğü	Microsoft Entra ID'de temsil edilmiyor.	Uygulama kayıtları uygulama kaydı; Kurumsal uygulamalarda service principal.
Fabric REST API desteği	Desteklenmez; destek planlanmamaktadır.	Belirli API ve işlemin hizmet sorumlularını kabul ettiği ve gerekli izinlerin mevcut olduğu durumlarda desteklenir.
Kimlik bilgisi aktarımı ve üst öğe eşleştirmesi	Profil üst service principal'lar arasında aktarılamaz.	Federe güven yeniden yapılandırılabilir; doğrudan kimlik bilgileri profil soyutlamasını yeniden oluşturmadan değiştirilebilir.

Bu tablo nasıl okunur: her iki düzenleme de müşteriler arasında kriptografik yalıtım sağlamaz. Kaynak yetkilendirmeleri erişimi zorunlu kılar ve çalışma zamanı müşterilere dolaylı olarak erişebilir. Profiller hafif kimlik ölçeklenebilirliği sunar. Ayrılmış ilkeler dizin idaresini, oturum açma görünürlüğünü ve API uyumluluğunu geliştirir. Önerilen yönetilen kimlik ve federasyon yolu, depolanan müşteri uygulaması kimlik bilgilerini de kaldırır.

Geçiş yolu

Aşağıdaki yol, profilleri ayrılmış müşteri hizmetleri temsilcileriyle değiştirir. Geçiş ve geri alma kararlarını her müşteri için ayrı tutun.

Profiller, yönetilen kimlik ve federasyon kimlik bilgileri

Küçük bir pilot kohort ve müşteri başına yayına alma anahtarıyla aşağıdaki geçiş aşamalarını kullanın. Doğrulama ve kararlaştırılan geri alma süresi tamamlanana kadar profil yolunu kullanılabilir durumda tutun.

0. Aşama: Uygulama yönetilen kimliği oluşturma

Uygulama için kullanıcı tarafından atanan yönetilen kimliği oluşturun ve işlem kaynağına atayın. Uygulama kılavuzu oluşturma ve atama komutlarını gösterir.
Asıl (nesne) kimliğini kaydedin. Her müşteri uygulamasının federasyon kimlik bilgileri, özne olarak bu değeri kullanır. Ayrıca istemci kimliğini, dizin kiracı kimliğini ve Azure kaynak kimliğini de kaydedin.

Uygulama için tek bir yönetilen kimlik kullanın, müşteri başına bir tane değil. Bu düzende her müşteri için ayrı bir MI gerekli değildir: müşteri kimliği service principal'dır ve MI assertion'ı sağlar. Daha büyük dağıtımlar veya daha küçük ihlal kapsamı için, müşterileri, her biri yalnızca kendisine atanmış müşteri uygulamaları alt kümesi tarafından güvenilen az sayıda çalışma zamanı kimliği arasında bölümleyin.

1. Aşama: Envanter

Tüm mevcut profilleri profile-management API aracılığıyla listeleyin:

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

Her profil için şunu kaydedin:

Profil kimliği ve görünen ad, üst service principal ve müşteri eşlemesi.
İlişkili çalışma alanları ve rol atamaları.
İlişkili anlamsal modeller veya veri kümeleri, raporlar ve diğer kaynaklar.
profile bağlı bağlantılar, veri kaynağı kimlik bilgileri, sahiplik bağımlılıkları, arka plan işleri ve API işlemleri.

Müşterinin yapılandırmasını değiştirmeden önce mevcut çalışma alanı rollerini, anlam modeli sahipliğini, bağlantı kimliklerini, kimlik bilgisi yapılandırmasını ve geri alma için gereken müşteriden profile eşlemeyi kaydedin. Gizli değerlere değil, kimlik bilgilerine güvenli başvurular kaydedin.

Devam etmeden önce toplam müşteri sayısını kaydedin ve gerekli uygulama ve hizmet asıl nesnelerini Microsoft Entra dizin nesnesi kotanızla karşılaştırın. 1.000 çalışma alanı üyelik sınırını ve kaynağa özgü sınırları da doğrulayın. Popülasyon tek bir dizinin kotasını aşarsa desteklenen bir kota artışı planlayın veya kasıtlı olarak yönetilen birden çok dizinli tasarım tasarlayın; bu model tarafından otomatik olarak çözülmez.

Not

Uç nokta gösterimi:{profile-api-base} çözümünüz tarafından zaten kullanılan mevcut, profil farkındalığı olan REST API temel URL'sini belirtir. Bu URL'yi dağıtım yapılandırmanızda tutun. Bu örnekler işlem yollarını korur; her yer tutucuyu yürütmeden önce değiştirin. profil farkında terimi, kullanımdan kaldırma durumunu değil API desteğini açıklar.

2. Aşama: Yeni kimlikler oluşturma

Her profil veya aynı müşteri yetkilendirme sınırına ait profil grubu için:

Bir uygulama kaydı ve hizmet sorumlusu nesnesi oluşturun. Uygulama istemci kimliğini, uygulama nesne kimliğini ve hizmet sorumlusu nesne kimliğini ayrı ayrı kaydedin.
0. Aşamada oluşturulan MI uygulamasına güvenen müşteri uygulaması kaydında federe kimlik bilgisini yapılandırın.
Yeni service principal’a aynı müşteri çalışma alanlarına ve kaynaklarına erişim verin. Envantere kaydedilen işlemlerin gerektirdiği Member'ı veya desteklenen en az ayrıcalıklı rolü kullanın. Yönetici yetkisini yalnızca gerektiğinde verin.

Desteklenen her yerde mevcut çalışma alanı ve kaynak kimliklerini koruyun. Çalışma alanı yetkilendirmesi kaynak sahipliğini, bağlantı kimliklerini veya veri kaynağı kimlik bilgilerini otomatik olarak aktarmaz. Tam geçiş öncesinde hizmete özgü güncelleştirmeleri tamamlayın.

3. Aşama: Uygulama kodunu güncelleştirme

Profil seçimi üst bilgisini ve SDK profil yapılandırmasını seçili müşteri uygulaması için yönetilen kimlik destekli belirteç değişimiyle değiştirin.
Uygulama veritabanınızda müşteriden kimliğe eşlemeyi güncelleştirin.

Önce	Sonra
`customerId -> profileId` tek bir paylaşılan SP kimlik bilgisi ve bir profil üst bilgisiyle	`customerId -> spClientId`, yönetilen kimlik belirteci değişimi yoluyla müşteri başına SP kimlik doğrulamasıyla Ayrıca dizin kiracı kimliğini, kimlik doğrulama yapılandırmasını ve izin verilen kaynak kimliklerini de koruyun.

Müşteri kimlikleri, Microsoft Entra kiracı kimlikleri olmak zorunda olmayan, ISV müşterilerinin mantıksal tanımlayıcılarıdır. Kimlik seçmeden önce kimliği doğrulanmış kullanıcının müşteri üyeliğini doğrulayın. Anahtar belirteçlerini dizin kiracısına, istemci kimliğine ve kaynağa veya kapsama göre önbelleğe alır.

Uygulamaya özgü belirteç oluşturma işlemini müşteri hizmet sorumlusu erişim belirtecini kullanacak şekilde güncelleştirin. Çözümünüz raporları veya diğer içerikleri gömüyorsa, bu belirteç oluşturma işlemini de güncelleştirin; gömme, bu kılavuz için bir önkoşul değil, taşınacak mevcut bir iş yüküdür.
Eski profil yapılandırmasını kullanarak çalışma alanı yönetimini, alt akış bağlantılarını, provizyon sağlamayı, zamanlanmış işleri ve diğer tüm giriş noktalarını güncelleştirin.

4. Aşama: Doğrulama

Her müşteri için şunları doğrulayın:

Çalışma alanı ve kaynak erişimi yeni servis sorumlusu aracılığıyla sağlanır.
Yönetilen kimlik belirteci alma ve federasyon belirteci değişimi hedeflenen müşteri uygulaması için başarıyla gerçekleştirilir.
Uygulamaya özgü belirteçler kullanıldıkları yerde başarıyla oluşturulur ve mevcut raporlar veya gömülü diğer içerikler uygun olan yerlerde doğru şekilde işlenir.
Yeni hizmet asıl sorumlusu oturum açma işlemleri Microsoft Entra ID'de görünür ve uygulama ve kaynak denetim günlükleriyle ilişkilendirilebilir.
Müşteriler arası erişim reddedildi: Arayan başka bir müşterinin uygulama kimliğini veya kaynak kimliklerini seçemez.

Üretime geçişten önce pilot müşteri için geri alma yordamını belgeleyin ve test edin. Geçiş sırasında değiştirilen herhangi bir semantik model sahipliğinin, bağlantı kimlik bilgilerinin, veri kaynağı kimlik bilgilerinin ve izinlerin geri yüklenmesini dahil edin. Önceki profilin geri alma sonrasında yenileme yapılandırması ve parametre güncelleştirmeleri de dahil olmak üzere gerekli işlemleri gerçekleştirebildiğini doğrulayın.

Müşterinin uygulama rotasını ancak kabul ölçütleri karşılandıktan sonra değiştirin. Dağıtımı genişletmeden önce hataları, performansı ve izinleri izleyin.

Doğrulama başarısız olursa, etkilenen arka plan işlerini duraklatın ve her hizmet için desteklenen yordamları kullanarak önceki yapılandırmayı geri yükleyin. Uygulama yolunu tek başına profile geri döndürmek, sahiplik veya kimlik bilgilerine bağlı işlemleri geri yüklemeyebilir. Gerekli yapılandırmayı geri yükledikten sonra profil tabanlı yola dönün ve işleri devam ettirmeden önce kaynak erişimini ve bağımlı işlemleri doğrulayın. Geri alma süresi boyunca özgün profilleri ve gerekli izinleri koruyun.

5. Aşama: Profilleri devreden çıkarma

Geri alma döneminden sonra, müşteriye özel hizmet sorumlularının gerekli erişime sahip olduğunu onayladıktan sonra eski özgün üst öğe ve profil çalışma alanı yetkilendirmelerini kaldırın.

Profil yönetimi API'si aracılığıyla taşınan her profili silin:

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

İsteğe bağlı olarak, müşteri, iş veya ilişkisiz iş yükü bunları hâlâ kullanmıyorsa özgün paylaşılan uygulama kaydını ve hizmet asıl nesnesini silin. Kullanımdan kaldırılmış kimlik bilgilerini devre dışı bırakın ve saklama gereksinimlerinize göre geçiş eşlemelerini ve denetim kayıtlarını koruyun.

Not

MI veya federasyon olmadan alternatif geçiş: Yönetilen kimlik ve federe kimlik bilgileri zorunlu değil, önerilir. Bunları kullanmak istemiyorsanız 0. Aşama'yı atlayın. 2. Aşamada, federasyon kimlik bilgileri yerine her müşteri uygulamasında bir sertifika veya desteklenen başka bir kimlik bilgisi yapılandırın. Aşama 3 ve 4'te erişim belirteçlerini doğrudan bu uygulama olarak alın ve doğrulayın. Aynı envanteri, kaynak izinlerini, müşteri yetkilendirmesini, dağıtımı ve devreden çıkarma adımlarını koruyun ve güvenli kimlik bilgisi depolama ve rotasyonunu yönetin.

Uygulama kılavuzu

Bu kılavuz önerilen yönetilen kimlik ve federe kimlik bilgileri yolunu uygular. Doğrudan kimlik doğrulaması alternatifi, aynı kimlik ve izin kurulumunu izler ve ana adımdan sonra açıklanır. Azure CLI örneklerde Bash söz dizimi kullanılır; yer tutucuları uygun değerlerle değiştirin ve çalıştırmadan önce hedeflenen dizinde ve abonelikte oturum açın.

Prerequisites

Önerilen yol için yönetilen kimlikler oluşturma ve atama izinleri olan bir Azure aboneliği.
uygulama kayıtları ve hizmet sorumluları oluşturmak ve uygulama kimlik bilgilerini güncelleştirmek için Microsoft Entra ID izinleri. Azure kaynak izinleri ve dizin izinleri ayrıdır.
App Service, Container Apps, uygun şekilde yapılandırılmış bir AKS iş yükü veya sanal makine gibi desteklenen Azure işlem kaynaklarında barındırılan bir uygulama. Bu desendeki MI destekli kanıt kaynağı, bu Azure barındırma yapılandırmasına bağlıdır.
Müşteriye çalışma alanı ve kaynak erişimi vermek, gerekli hizmet ayarlarını yapılandırmak ve hedef hizmetin gerektirdiği durumlarda API izinleri veya onayı vermek için yönetim izinleri.
Azure CLI yüklü ve doğru dizin kiracısında oturum açılmış. Azure kaynakları oluşturmadan önce abonelik bağlamını onaylayın.

Geliştirici kiracı ayarları

Kiracı ayarları ve geliştirici ayarları altında hizmetinizin yönetim arabirimindeki ilgili ayarları gözden geçirin. Hizmet sorumlusu erişimini, müşteri hizmet sorumlularını içeren izin verilen bir güvenlik grubuyla sınırlandırın. Tam etiketler ve geçerli davranış için bkz. geliştirici tenant ayarları.

Çözümünüz için gereken her grup kapsamındaki ayar için, test veya tam geçiş öncesinde her yedek hizmet sorumlusunu izin verilen bir güvenlik grubuna ekleyin. Özgün üst hizmet ilkesine verilen erişim, yerine geçen ilkeleri otomatik olarak yetkilendirmez. public API erişim ayarı hem mevcut profil kullanan REST API'leri hem de Fabric REST API'leri için geçerlidir; yalnızca kimliğin taşınması bu önkoşulu kaldırmaz.

Aşağıdaki genel API ayarı, üründen bağımsız bir etiket kullanır; yönetim arabirimi hizmetin adını içerebilir.

Setting	Yayımlanmış varsayılan	Gerekli olduğunda
Servis sorumluları genel kullanıma açık API'leri çağırabilir	Yeni müşteriler için etkinleştirildi.	Müşteri hizmetleri hizmet sorumluları, mevcut profil kullanan REST API'lerini veya Fabric REST API'lerini çağırır. Ayar grup kapsamındaysa, izin verilen güvenlik grubuna her yedek asıl öğeyi ekleyin.
Hizmet sorumluları çalışma alanları, bağlantılar ve dağıtım işlem hatları oluşturabilir	Yeni müşteriler için devre dışı bırakıldı.	Uygulama bu kaynakları sağlar.
Uygulamalara içerik ekleme	Mevcut yapılandırmalarda etkin; tenant’ınızı doğrulayın.	Mevcut uygulamanız geçerli REST API'leri aracılığıyla içeriği gömer.
Hizmet sorumlularının profil oluşturmasına ve kullanmasına izin ver	Bir varsayılan olduğunu varsaymayın.	Yalnızca müşteriler profil yolunu kullanmaya devam ederken; taşınan müşteriler için gerekli değildir.

Varsayılanları varsayma yerine gerçek değerleri doğrulayın. Yeni ve mevcut kiracılar farklı olabilir ve yöneticiler ayarları değiştirebilir. Her bağımlı müşteri ve iş taşınana kadar profil ayarını koruyun. Embedding kullanmayan bir iş yükü için embedding ayarlarını etkinleştirmeyin.

1. Adım: Kullanıcı tarafından atanan yönetilen kimliği oluşturma ve atama

Bu yönetilen kimlik, bireysel bir müşteriyi değil ISV uygulamasını temsil eder. Mevcut bir kaynak grubunu kullanın:

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

İstemci kimliğini, asıl (nesne) kimliğini, dizin kiracısı kimliğini ve Azure kaynak kimliğini kaydedin. Hesaplama kaynağına atayın. Mevcut bir App Service uygulaması için:

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

Diğer işlem hizmetleri için ilgili kimlik atama yordamını kullanın. Çalışma zamanında bu kullanıcı tarafından atanan yönetilen kimliği açıkça seçin. Kimlik host kaynağından bağımsız olduğundan, bir hostu yeniden dağıtmak için her müşteri güven ilişkisinin değiştirilmesi gerekmez.

2. Adım: Her müşteri için bir service principal oluşturma

Mevcut profillerin temsil ettiği her müşteri, kullanıcı veya grup sınırı için bir uygulama kaydı ve hizmet sorumlusu (service principal) oluşturun. Bu örnek, ISV'nin dizininde tek kiracılı bir uygulama oluşturur:

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)

Tanımlayıcı	Kullan
Uygulama istemci kimliği	Erişim belirteci isteğinde bulunurken müşteri uygulamasını tanımlayın.
Uygulama nesne kimliği	Uygulama kaydında federasyon kimlik bilgilerini yapılandırın.
Hizmet sorumlusu nesne kimliği	API principal nesne kimliğini gerektirdiğinde çalışma alanı veya kaynak rolleri verin.

Not

Önerilen yol kimlik bilgileri: Bu kimlik doğrulama yolu için bir istemci gizli anahtarı veya sertifika oluşturmayın. Müşteri uygulamasının federe güven ilişkisi kimlik doğrulama mekanizmasını sağlar.

3. Adım: Federe kimlik bilgilerini yapılandırma

Yönetilen kimlik asıl kimliğini ve dizin kiracı kimliğini alın. Farklı bir geçerli aboneliğin aynı kiracıya sahip olduğunu varsaymak yerine kimliğin kiracısını kullanın:

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)

Her müşteri uygulaması kaydına bir federe kimlik bilgisi ekleyin. Aşağıdaki genel bulut komutu, 2. Adımdaki uygulama nesnesi kimliğini ve az önce alınan MI değerlerini kullanır:

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

Alternatif olarak, yerel bir credential.json dosyada yerine geçen değerlerle aynı JSON'ı kaydedin ve --parameters credential.json parametresini iletin. Her müşteri uygulamasında güven ilişkisini yineleyin. Token değişimini doğrulamadan önce yapılandırmanın yayılması için süre tanıyın.

4. Adım: Her hizmet sorumlusuna çalışma alanı erişimi verin

Müşteri hizmetleri sorumlusunu yalnızca bu rolün gerekli olduğu belirlenen çalışma alanlarına Üye veya Yönetici olarak ekleyin. İşlem gereksinimlerini karşılıyorsa daha düşük bir desteklenen rolü tercih edin. Müşterinin kaynak erişiminin kapsamını aslında bu yetki ataması belirler.

Çalışma alanı yönetim arabirimini veya çalışma alanı rol atama REST işlemini kullanın. Aşağıdaki örnekte yapılandırılabilir API ve kaynak tanımlayıcıları kullanılır. Yetkili bir hazırlama kimliği gerektirir; çalışma zamanı MI'sinin kendisine belirteç değişimi için müşteri kaynak izinleri verilmez.

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

Mevcut çalışma alanının sahibi olan hizmet için belgelenen uç noktayı ve istek şeklini kullanın. Görüntülenen işlem, profil farkındalıklı çalışma alanı API'sine uygulanır; diğer API'ler farklı rol atama şemaları kullanabilir. İşlemin hizmet sorumlusu nesne kimliği beklediği yerde istemci kimliği kullanmayın. Bearer tokenlarını günlüğe kaydetmekten kaçının ve izin yayılımını destekleyin.

5. Adım: API'lerin kimliğini doğrulama ve çalışma zamanında çağırma

Kimliği doğrulanmış müşterinin uygulama istemci kimliğini ve izin verilen kaynaklarını güvenilen sunucu tarafı yapılandırmasından belirleyin.
Seçilen kullanıcı tarafından atanan yönetilen kimliği ve genel buluttaki api://AzureADTokenExchange/.default kapsamı kullanarak onaylama belirteci alın.
MI belirtecini müşteri uygulaması için istemci beyanı olarak kullanın. Onay hedef kitlesine değil, kaynak API'sinin uygulama kapsamına sahip bir erişim belirteci isteyin.
Bu müşteri uygulaması erişim belirtecini kullanarak ve profil seçimi yapılandırması olmadan hedef API'yi çağırın. Çalışma alanlarını yönetin, uygulamaya özgü gerekli belirteçleri isteyin ve müşteri kimliği aracılığıyla envantere kaydedilmiş diğer işlemleri gerçekleştirin.

.NET için, assertion geri çağırması olarak yönetilen kimlik belirtecini kullanan Azure Identity ClientAssertionCredential kullanın. Altı adımlı akış ve resmi yapılandırma örnekleri, gömme işlemine özgü bir uygulama kodu örneği gerektirmeden değişimi gösterir.

İşe alım ve işten çıkarma sürecini otomatikleştirme

Sağlama işlem hattınızda dört ilk yapılandırma işlemini tek bir işlem hattında birleştirin: uygulama kaydını oluşturun, hizmet sorumlusunu oluşturun, federe güveni yapılandırın ve çalışma alanı rolünü verin. Eşleşen offboarding sürecini aynı anda oluşturun: kaynak izinlerini kaldırın, eski güven veya kimlik bilgilerini iptal edin ve yalnızca bağımlılıkları denetledikten sonra uygulama kimliklerini silin.

Alternatif uygulama: Hizmet sorumlularının kimliğini doğrudan doğrulama

MI ve federasyon kullanmak istemiyorsanız 1. ve 3. adımları atlayın. Her müşteri için 2. Adımı tamamlayın ve federasyon güveni yerine desteklenen bir uygulama kimlik bilgilerini yapılandırın.

Desteklenen bir sertifika kullanın ve uygulama kimlik bilgisi kurulum yönergelerini izleyin. Genel sertifikayı karşıya yükleyin, uygun bir kimlik bilgisi deposunda özel anahtarı koruyun ve yenilemeyi otomatikleştirin. Bir istemci gizli dizisi gerekiyorsa, gizli diziyi koruyun ve süresi dolmadan önce yenileyin.

4. Adımı aynı en az ayrıcalıklı müşteri yetkileriyle tamamlayın. 5. Adım'da, doğrudan istemci kimlik bilgileri erişim belirteci istemek için müşteri istemci kimliğini ve kimlik bilgisini kullanın. Aynı müşteri yönlendirmesini, belirteç önbelleği ayrımını, doğrulamayı ve geçiş temizleme denetimlerini koruyun.

Güvenlik, sınırlamalar ve dikkat edilmesi gerekenler

Seçtiğiniz kimlik doğrulama yoluna aşağıdaki denetimleri uygulayın ve çalışma sınırlarını göz önünde bulundurun.

Güvenlik önerileri

Kullanıcı tarafından atanan sabit bir yönetilen kimlik kullanın. Bu, yalnızca bir işlem kaynağının değiştirilmesi nedeniyle müşteri güveninin kaybedilmesini önler. Bu app-trust düzeni için assertion kaynağı olarak sistem tarafından atanan bir kimlik kullanmayın.
Uygulama MI'sini yüksek ayrıcalıklı bir kimlik olarak değerlendirin. Kendisine güvenen her müşteri uygulaması gibi kimlik doğrulaması yapabilir. İşlem dağıtım haklarını, yönetilen kimlik atamalarını, uygulama sahiplerini ve kimlik bilgisi yönetimini kısıtlayın. Ele geçirilme kapsamını azaltmak için gerekirse çalışma zamanı kimliklerini bölümleyin.
MI'ye kendine ait hiçbir müşteri hizmeti izni vermeyin. Bu bir assertion kaynağıdır; müşteri hizmeti asılları workspace ve downstream hizmet yetkilerini alır.
Kiracı ayarlarını bir güvenlik grubuyla sınırlandırın. Kuruluşun tamamı için service principal erişimini etkinleştirmek yerine izin verilen gruba ilgili tüm müşteri service principal’larını ekleyin.
Her hizmet sorumlusunun (service principal) oturum açma işlemlerini izleyin ve bunlar için uyarı oluşturun. Uygulama ve kaynak günlükleriyle ilişkilendirin. Müşteriye özgü araştırma ve uyarı olmadan günlükleri toplamak operasyonel avantaj sağlamaz.
Birlikte işe alım ve işten ayrılma süreçlerini otomatikleştirin. Çalışma alanı rollerini kaldırma, kimlik bilgilerini veya güven ilişkilerini kullanımdan kaldırma ve eski hizmet asıllarını silme, bunları oluşturmak kadar denetlenebilir ve yinelenebilir olmalıdır.

Müşteri eşlemelerini sunucu tarafında tutun, bir kimlik seçmeden önce üyeliği doğrulayın ve rastgele istemci tarafından sağlanan kimlik veya kaynak kimliklerini reddedin. Belirtecin yeniden kullanılması, bir oturum açma kaydının her API çağrısının kaydı olmadığı anlamına gelir. Gizli bilgileri, assertion'ları, erişim belirteçlerini veya sertifika özel anahtarlarını günlüğe kaydetmeyin.

Sınırlamalar ve operasyonel gereksinimler

Consideration	Neler için plan yapılmalı
Profillerle karşılaştırıldığında ölçek üst sınırı	Profiller üst hizmet asıl öğesi başına 100.000'e izin verir ve profil başına en fazla 1.000 çalışma alanı olur. Ayrılmış uygulama kayıtları ve hizmet asılları dizin nesnelerini kullanır. İşlemeden önce dizin kotalarını, hizmet sorumlusu çalışma alanı sınırlarını ve sağlama işleme hızını denetleyin.
Federe kimlik bilgileri sınırı	Uygulama kaydı en fazla 20 federe kimlik bilgisini destekler. Bu mimari genellikle paylaşılan bir uygulamada müşteri başına bir tane değil, her müşteri uygulamasında güvenilen her çalışma zamanı yönetilen kimliği için bir tane gerektirir.
Aynı tenant gereksinimi	Yönetilen kimlik ve güvenen her uygulama kaydı aynı Microsoft Entra dizinine ait olmalıdır. Başka bir kiracıdaki kaynaklara erişim için ayrıca desteklenen bir uygulama yapılandırması, onayı ve kaynak izinleri gerekir.
Bulutlar arası belirteç değişimi yok	Küresel bulut ve ABD Kamu gibi farklı Azure bulutları arasında belirteç alışverişi yapmayın. Hedef buluttaki doğru hedef kitle ve yetki uç noktalarını kullanın.
Azure compute gereksinimi	Yönetilen kimlik destekli assertion akışı, desteklenen bir Azure barındırma ortamının yönetilen kimlik mekanizmasını gerektirir. Uygulama başka bir yerde çalışıyorsa veya bu düzeni kullanmak istemiyorsanız doğrudan kimlik doğrulama alternatifini veya desteklenen başka bir federasyon tasarımını kullanın.
Koşullu Erişim	Microsoft Entra İş Yükü Kimliği Premium, iş yükü kimliği Koşullu Erişim ilkeleri oluşturmak veya değiştirmek için gereklidir. Politikalar, kuruluşa ait uygun tek kiracılı hizmet asıllarını kapsar ve bunları doğrudan hedeflemelidir. Yönetilen kimlikleri kapsamaz veya yalnızca grup üyeliği aracılığıyla etkili olmaz.
Geliştirici kiracı ayarları	Grup kapsamlı bir ayar kullanan her müşteri hizmetleri asıl öğesi, izin verilen güvenlik grubunda olmalıdır. Uygulama önkoşullarındaki dört ayarı gözden geçirin; varsayılanları varsaymayın.
Automation	Yüzlerce veya binlerce müşteri kimliğinin el ile yönetilmesi pratik değildir. Sağlamayı otomatikleştirin, yetki değişikliklerini uygulayın, izleme, döndürme veya güven güncelleştirmeleri ve hizmetten çıkarma. Sınırlanmış yeniden denemeler ve bekleme süresini kademeli artırma ile hız sınırlamayı işleyin.
Yalnızca devredilmiş yetkiyle kullanılan deneyimler kapsam dışında kalıyor	Profillerin değiştirilmesi, bir iş yükünün temsilci kullanıcı belirteçleri gerektirdiği durumlarda yalnızca uygulama kimlik doğrulamasını etkinleştirmez. Real-Time Panosu ekleme önizlemesinde yalnızca bu öğe türü ve temsilci kullanıcı kimlik doğrulaması desteklenir; app-only ve app-owns-data belirteçleri desteklenmez. Mevcut rapor ekleme, ilgili hizmete özgü mekanizmasını kullanır.

Kapasite ve izinleri kesinleştirmeden önce Microsoft Entra hizmet sınırlarına ve hedef hizmetin API kimliği desteğine başvurun.

Geçerli güven sınırları ve yayılma davranışı için bkz. federe kimlik bilgisiyle ilgili dikkat edilmesi gerekenler.

Geçerli ilkeye uygunluk ve lisanslama için bkz. İş yükü kimlikleri için Koşullu Erişim.

Küresel bulut token-exchange hedef kitlesini api://AzureADTokenExchange, ABD Hükümeti hedef kitlesini api://AzureADTokenExchangeUSGov veya Çin hedef kitlesini api://AzureADTokenExchangeChina, uygun şekilde kullanın. Yetki uç noktasını bulutla eşleştirin. Bu makaledeki örneklerde genel bulutta kullanılır.

Belirteç önbelleğe alma ve yenileme için desteklenen kimlik kitaplıklarını kullanın. Güven ve izin yayılımına izin verin, geçici hataları sınırlı bekleme artışıyla yeniden deneyin ve kalıcı issuer, özne veya hedef kitle uyuşmazlıklarını araştırın. Doğrudan kimlik doğrulaması için sertifikaları ve gizli anahtarları örtüşme süresiyle döndürün ve süre sonunu izleyin.

Profili silmenin, kimlik bilgilerini kaldırmanın veya güven ilişkisini değiştirmenin önceden verilen belirteçleri anında geçersiz kıldığını varsaymayın. Tam geçiş ve sistemden çıkarma planlarken belirteç ömrünü ve her kaynak hizmetinin yetkilendirme ve iptal davranışını dikkate alın.

API'ye özgü izinler, geçerli kimlik kısıtlamaları ve mevcut iş yükü yapılandırması için bu referansları kullanın.