Senaryo - SAP platformlarına ve uygulamalarına erişimi güvenli bir şekilde sağlamak için Microsoft Entra Id kullanma

Bu belge, SAP Cloud Identity Services için birincil kullanıcı kimlik doğrulama hizmeti olarak Microsoft Entra ID kullanılırken SAP platformlarının ve uygulamalarının teknik tasarımı ve yapılandırması hakkında öneriler sağlar. SAP Cloud Identity Services, Kimlik Doğrulaması, Kimlik Sağlama, Kimlik Dizini ve Yetkilendirme Yönetimi'ni içerir. SAP Cloud Identity Services ile Microsoft Entra çoklu oturum açma (SSO) tümleştirmesi öğreticisinde kimlik doğrulaması için ilk kurulum hakkında daha fazla bilgi edinin. Sağlama ve diğer senaryolar hakkında daha fazla bilgi için bkz . SAP kaynak ve hedef uygulamalarıyla kullanıcı sağlama için Microsoft Entra dağıtmayı planlama ve SAP uygulamalarınıza erişimi yönetme.

Bu kılavuzda kullanılan terimler

Genel bakış

SAP ve Microsoft teknoloji yığınında kullanıcı kimlik doğrulaması ve yetkilendirme senaryolarında rol oynayan birçok hizmet ve bileşen vardır. Ana hizmetler aşağıdaki diyagramda listelenmiştir.

Yapılandırılacak olası senaryoların birçok permütasyonu olduğundan, microsoft entra kimlik ilk stratejisiyle uyumlu olan bir senaryoya odaklanıyoruz. Aşağıdaki varsayımları yapacağız:

• Tüm kimliklerinizi merkezi olarak ve yalnızca Microsoft Entra Id'den yönetmek istiyorsunuz.
• Bakım çalışmalarını mümkün olduğunca azaltmak ve Microsoft ve SAP genelinde kimlik doğrulaması ve uygulama erişimini otomatikleştirmek istiyorsunuz.
• IAS ile Microsoft Entra Id için genel kılavuz, IAS'de yapılandırılmış BTP ve SAP SaaS uygulamalarına dağıtılan uygulamalar için geçerlidir. BTP (örneğin, Microsoft Entra gruplarıyla rol eşlemelerini kullanma) ve SAP SaaS uygulamaları (örneğin, rol tabanlı yetkilendirme için kimlik sağlama hizmetini kullanma) için geçerli olduğunda belirli öneriler de sağlanacaktır.
• Ayrıca, kullanıcıların Microsoft Entra ID'de ve kullanıcıların çalışması için sağlanmasını gerektiren tüm SAP sistemlerine yönelik olarak zaten sağlandığını varsayıyoruz. Bunun nasıl gerçekleştirildiğine bakılmaksızın: sağlama el ile, şirket içi Active Directory'dan Microsoft Entra Bağlan'a veya SAP SuccessFactors gibi İk sistemleri aracılığıyla yapılabilirdi. Bu nedenle bu belgede SuccessFactors, diğer (mevcut) kullanıcıların oturum açacağı uygulamalar gibi bir uygulama olarak kabul edilir. SuccessFactors'tan Microsoft Entra Id'ye kullanıcıların gerçek sağlamasını kapsamayız. Sap iş yükleriyle kullanılmak üzere kullanıcıları Microsoft Entra ID'ye getirme hakkında daha fazla bilgi için bkz . SAP kaynağı ve hedef uygulamalarıyla kullanıcı sağlama için Microsoft Entra dağıtmayı planlama ve SAP uygulamalarınıza erişimi yönetme.

Bu varsayımlara dayanarak, çoğunlukla aşağıdaki diyagramda sunulan ürün ve hizmetlere odaklanıyoruz. Bunlar, bulut tabanlı bir ortamda kimlik doğrulaması ve yetkilendirmeyle en ilgili olan çeşitli bileşenlerdir.

SAP Identity Management (IDM) kullanıyorsanız, kimlik yönetimi senaryolarını SAP IDM'den Microsoft Entra'ya geçirebilirsiniz. Daha fazla bilgi için bkz . Kimlik yönetimi senaryolarını SAP IDM'den Microsoft Entra'ya geçirme.

Öneriler

Özet

• 1 - SAP Kimlik Doğrulama Hizmeti aracılığıyla SAP İş Teknolojisi Platformu ve SAP SaaS uygulamalarında Federasyon Kimlik Doğrulaması kullanma
• 2 - Kimlik Doğrulaması için Microsoft Entra Id ve Yetkilendirme için IAS/BTP kullanma
• 3 - IAS/BTP'de Rol Koleksiyonları Aracılığıyla Yetkilendirme için Microsoft Entra gruplarını kullanma
• 4 - Yalnızca benzer Kimlik gereksinimlerine sahip uygulamalar için tek bir BTP Alt Hesabı kullanın
• 5 - Tüm son kullanıcı Kimlik Doğrulaması ve Yetkilendirmesi için Üretim IAS kiracısını kullanın
• 6 - SAML İmzalama Sertifikalarının Geçişi için bir İşlem Tanımlama

1 - SAP Kimlik Doğrulama Hizmeti aracılığıyla SAP İş Teknolojisi Platformu ve SAP SaaS uygulamalarında Federasyon Kimlik Doğrulaması kullanma

Bağlam

BTP'deki uygulamalarınız, BTP/XSUAA ile kimlik sağlayıcısı arasındaki SAML 2.0 protokolunu kullanarak kullanıcıların kimliğini doğrulamak için Güven Yapılandırmaları aracılığıyla kimlik sağlayıcılarını kullanabilir. Uygulamanın kendisi ile BTP/XSUAA (bu bağlamda ilgili değil) arasında OpenID Bağlan protokolü kullanılsa bile yalnızca SAML 2.0'ın desteklendiğini unutmayın.

BTP'de SAP Cloud Identity Services - Identity Authentication (varsayılandır) için bir güven yapılandırması ayarlamayı seçebilirsiniz, ancak yetkili kullanıcı dizininiz Microsoft Entra ID olduğunda, kullanıcıların mevcut Microsoft Entra hesaplarıyla oturum açabilmesi için federasyonu ayarlayabilirsiniz.

Federasyona ek olarak, microsoft Entra kullanıcılarının BTP'de önceden sağlanması için isteğe bağlı olarak kullanıcı sağlamayı da ayarlayabilirsiniz. Ancak, bunun için yerel destek yoktur (yalnızca Microsoft Entra ID -> SAP Identity Authentication Service için); yerel desteğe sahip tümleşik bir çözüm BTP Kimlik Sağlama Hizmeti olacaktır. Kullanıcı hesaplarının önceden sağlanması yetkilendirme amacıyla (örneğin, rollere kullanıcı eklemek için) yararlı olabilir. Ancak gereksinimlere bağlı olarak, bunu Microsoft Entra gruplarıyla da yapabilirsiniz (aşağıya bakın), bu da kullanıcı hazırlamaya hiç ihtiyacınız olmadığı anlamına gelebilir.

Federasyon ilişkisini ayarlarken birden çok seçenek vardır:

• Doğrudan BTP/XSUAA'dan Microsoft Entra Id'ye federasyon yapmayı seçebilirsiniz.
• IAS ile federasyon yapmayı seçebilirsiniz. Bu, kurumsal kimlik sağlayıcısı olarak Microsoft Entra id ile federasyon olarak ayarlanır ("SAML Proxy'si" olarak da bilinir).

SAP SaaS uygulamaları için IAS, son kullanıcıların kolayca eklenmesi için sağlanır ve önceden yapılandırılır. (Buna örnek olarak SuccessFactors, Marketing Cloud, Cloud for Customer, Sales Cloud ve diğerleri verilebilir.) IAS doğrudan hedef uygulamayla bağlantılı olduğundan ve XSUAA'ya bağlı olmadığından bu senaryo daha az karmaşıktır. Her durumda, bu kurulum için, genel olarak IAS ile Microsoft Entra Id ile aynı kurallar geçerlidir.

Ne öneriyoruz?

Yetkili kullanıcı dizininiz Microsoft Entra Id olduğunda, BTP'de IAS'ye doğru bir güven yapılandırması ayarlamanızı öneririz. IAS de Kurumsal Kimlik Sağlayıcısı olarak Microsoft Entra Kimliği ile federasyon oluşturacak şekilde ayarlanır.

BTP'deki güven yapılandırmasında "Oturum Açma Sırasında Gölge Kullanıcı Oluşturma" özelliğinin etkinleştirilmesini öneririz. Bu şekilde, HENÜZ BTP'de oluşturulmamış kullanıcılar IAS / Microsoft Entra Id aracılığıyla ilk kez oturum açtıklarında otomatik olarak bir hesap alır. Bu ayar devre dışı bırakılacaksa, yalnızca önceden sağlanan kullanıcıların oturum açmasına izin verilir.

Neden bu öneri?

Federasyon kullanırken BTP Alt Hesap düzeyinde güven yapılandırmasını tanımlamayı seçebilirsiniz. Bu durumda, kullandığınız alt hesap için yapılandırmayı yinelemeniz gerekir. IAS'yi ara güven yapılandırması olarak kullanarak, birden çok Alt hesapta merkezi yapılandırmadan yararlanabilir ve risk tabanlı kimlik doğrulaması ve onay özniteliklerinin merkezi zenginleştirilmesi gibi IAS özelliklerini kullanabilirsiniz. Kullanıcı deneyimini korumak için bu gelişmiş güvenlik özellikleri yalnızca tek bir konumda zorunlu kılınmalıdır. Bu IAS olabilir veya Microsoft Entra Id'yi tek yetkili kullanıcı deposu olarak tutarken (bu makalenin şirket içinde olduğu gibi), bu işlem Microsoft Entra Koşullu Erişim Yönetimi tarafından merkezi olarak ele alınır.

Not: IAS için, her Alt Hesap bir "uygulama" olarak kabul edilir, ancak bu Alt hesap içinde bir veya daha fazla uygulama dağıtılabilir. IAS içinde, bu tür her uygulama aynı kurumsal kimlik sağlayıcısıyla (bu örnekte Microsoft Entra Kimliği) federasyon için ayarlanabilir.

Uygulamanın özeti

Microsoft Entra Id'de:

• İsteğe bağlı olarak Microsoft Entra Id'yi sorunsuz çoklu oturum açma (Sorunsuz SSO) için yapılandırın. Bu kimlik, kullanıcıları şirket ağınıza bağlı şirket cihazlarında olduklarında otomatik olarak oturum açar. Bu özellik etkinleştirildiğinde kullanıcıların Microsoft Entra ID’de oturum açmak için parola yazmalarına gerek kalmaz. Çoğu durumda kullanıcı adı yazmalarına bile gerek yoktur.

Microsoft Entra Id ve IAS'de:

• Microsoft Entra Id'yi IAS'ye federasyon (proxy) modunda (SAP doc, Microsoft doc) bağlamak için belgeleri izleyin. UPN'lerin e-posta adresleri olması gerekemediğinden NameID Microsoft Entra Id'de SSO yapılandırmanızdaki ayara dikkat edin.
• "Koşullu Kimlik Doğrulama" sayfasına gidip "Varsayılan Kimlik Doğrulama Kimlik Sağlayıcısı"nı Microsoft Entra dizininizi temsil eden Kurumsal Kimlik Sağlayıcısı olarak ayarlayarak "Paketlenmiş Uygulama" öğesini Microsoft Entra Kimliğini kullanacak şekilde yapılandırın.

BTP'de:

• IAS 'ye (SAP belgesi) yönelik bir güven yapılandırması ayarlayın ve "Kullanıcı Oturumu Için Kullanılabilir" ve "Oturum Açma Sırasında Gölge Kullanıcılar Oluştur" seçeneğinin etkinleştirildiğinden emin olun.
• İsteğe bağlı olarak, varsayılan "SAP ID Hizmeti" güven yapılandırmasında "Kullanıcı Oturum Açma için Kullanılabilir" seçeneğini devre dışı bırakın; böylece kullanıcılar her zaman Microsoft Entra Id aracılığıyla kimlik doğrulaması yapar ve kimlik sağlayıcılarını seçmek için bir ekran sunulmaz.

2 - Kimlik Doğrulaması için Microsoft Entra Id ve Yetkilendirme için IAS/BTP kullanma

Bağlam

BTP ve IAS, Federasyon aracılığıyla Microsoft Entra Id'ye doğru kullanıcı kimlik doğrulaması için yapılandırıldığında, yetkilendirmeyi yapılandırmak için birden çok seçenek vardır:

• Microsoft Entra Kimliği'nde Microsoft Entra kullanıcılarını ve gruplarını, Microsoft Entra Id'deki SAP IAS örneğinizi temsil eden Kurumsal Uygulamaya atayabilirsiniz.
• IAS'de, risk tabanlı kimlik doğrulamasını kullanarak oturum açma işlemlerine izin verebilir veya bunları engelleyebilir ve bunu yaparak BTP'de uygulamaya erişimi engelleyebilirsiniz.
• BTP'de, hangi kullanıcıların ve grupların uygulamaya erişebileceğini ve belirli rolleri alabileceğini tanımlamak için Rol Koleksiyonları'nı kullanabilirsiniz.

Ne öneriyoruz?

Herhangi bir yetkilendirmeyi doğrudan Microsoft Entra'nın kendisine yerleştirmemenizi ve Microsoft Entra Id'deki Kurumsal Uygulama'da "Kullanıcı ataması gerekiyor" özelliğini açıkça kapatmanızı öneririz. SAML uygulamaları için bu ayarın varsayılan olarak etkinleştirildiğini, bu nedenle devre dışı bırakmak için açık bir işlem yapmanız gerektiğini unutmayın.

Neden bu öneri?

Uygulama IAS aracılığıyla federasyona eklendiğinde, Microsoft Entra Id açısından bakıldığında, kullanıcı oturum açma akışı sırasında temelde "IAS'de kimlik doğrulaması" yapılır. Bu, Microsoft Entra Id'nin kullanıcının oturum açmaya çalıştığı son BTP uygulaması hakkında bilgi olmadığı anlamına gelir. Bu, Microsoft Entra Id'deki yetkilendirmenin yalnızca çok ayrıntılı yetkilendirme yapmak için kullanılabileceği anlamına gelir; örneğin, kullanıcının BTP'deki herhangi bir uygulamada oturum açmasına izin verme veya hiç kullanmama. Bu, SAP'nin BTP Alt Hesap düzeyinde uygulamaları ve kimlik doğrulama mekanizmalarını yalıtma stratejisini de vurgular.

Bu, "Kullanıcı ataması gerekli" ifadesinin kullanılması için geçerli bir neden olsa da, artık yetkilendirme bilgilerinin korunması gereken iki farklı yer olduğu anlamına gelir: hem Kurumsal Uygulama'daki Microsoft Entra Kimliği'nde (tüm BTP uygulamaları için geçerli olduğu yerde), hem de her BTP Alt Hesabı'nda. Bu, yetkilendirme ayarlarının bir yerde güncelleştirildiği ancak diğerinde güncelleştirilmediği karışıklığa ve yanlış yapılandırmalara neden olabilir. Örneğin: BtP'de bir kullanıcıya izin verildi, ancak Microsoft Entra Id'de uygulamaya atanmadı ve bu da kimlik doğrulamasının başarısız olmasına neden oldu.

Uygulamanın özeti

IAS ile federasyon ilişkisini temsil eden Microsoft Entra Enterprise Uygulaması'nda "Kullanıcı ataması gerekli" seçeneğini devre dışı bırakın. Bu, kullanıcıların atamalarını güvenli bir şekilde atlayabileceğiniz anlamına da gelir.

3 - IAS/BTP'de Rol Koleksiyonları Aracılığıyla Yetkilendirme için Microsoft Entra gruplarını kullanma

Bağlam

BTP uygulamalarınız için yetkilendirmeyi yapılandırmak istediğinizde birden çok seçenek vardır:

• Oturum açmış kullanıcıya göre uygulamanın kendi içinde ayrıntılı erişim denetimi yapılandırabilirsiniz.
• Kullanıcı atamalarına veya grup atamalarına göre BTP'deki Roller ve Rol Koleksiyonları aracılığıyla erişim belirtebilirsiniz.

Son uygulama her iki stratejinin bir bileşimini kullanabilir. Ancak, Rol Koleksiyonları aracılığıyla atama için bu işlem kullanıcı bazında yapılabilir veya yapılandırılan kimlik sağlayıcısı gruplarını kullanabilir.

Ne öneriyoruz?

Ayrıntılı yetkilendirme için yetkili kaynak olarak Microsoft Entra Id kullanmak istiyorsanız, Microsoft Entra gruplarını kullanmanızı ve btp'deki Rol Koleksiyonlarına atamanızı öneririz. Kullanıcılara belirli uygulamalara erişim vermek, IAS/BTP'de başka bir yapılandırma gerekmeden bunları ilgili Microsoft Entra gruplarına eklemek anlamına gelir.

Bu yapılandırmayla, Microsoft Entra grubunun Grup Kimliğini (Nesne Kimliği) görünen adı ("sAMAccountName") değil, grubun benzersiz tanımlayıcısı olarak kullanmanızı öneririz. Bu, Microsoft Entra Id tarafından verilen SAML belirtecinde "Gruplar" onayı olarak Grup Kimliğini kullanmanız gerektiği anlamına gelir. Buna ek olarak, BTP'de Rol Koleksiyonu'na atama için Grup Kimliği kullanılır.

Neden bu öneri?

Kullanıcıları doğrudan BTP'deki Rol Koleksiyonları'na atarsanız, Yetkilendirme kararlarını Microsoft Entra Id'de merkezileştiremezsiniz. Ayrıca, BTP'de rol koleksiyonuna atanabilmesi için kullanıcının IAS'de zaten var olması gerektiği anlamına gelir ve kullanıcı sağlamak yerine federasyon önerilir. Bu, kullanıcının gölge hesabının henüz kullanıcı atamasını yapmak istediğiniz sırada IAS'de mevcut olmadığı anlamına gelir. Microsoft Entra gruplarını kullanmak ve bunları Rol Koleksiyonları'na atamak bu sorunları ortadan kaldırır.

Rol Koleksiyonları'na grup atamak, yetkilendirme için Microsoft Entra Id kullanmama önerisiyle çelişiyor gibi görünebilir. Ancak bu durumda bile BTP'de yetkilendirme kararı alınmaya devam etmektedir. Bu karar artık Microsoft Entra Id'de tutulan grup üyeliğine dayanmaktadır.

Grup Kimliği genel olarak benzersiz, sabit olduğundan ve daha sonra başka bir grup için hiçbir zaman yeniden kullanılamayacağından, Adı yerine Microsoft Entra grubunun Grup Kimliğini kullanmanızı öneririz; ancak grup adının kullanılması, ad değiştirildiğinde sorunlara yol açabilir ve bir grubun silinmesi ve bir grubun aynı adla ancak içinde uygulamaya erişimi olmaması gereken kullanıcılarla oluşturulmasında güvenlik riski vardır.

Uygulamanın özeti

Microsoft Entra Id'de:

• BTP'deki uygulamalara erişmesi gereken kullanıcıların eklenebileceği gruplar oluşturun (örneğin, BTP'deki her Rol Koleksiyonu için bir Microsoft Entra grubu oluşturun).
• IAS ile federasyon ilişkisini temsil eden Microsoft Entra Enterprise Uygulaması'nda, SAML Kullanıcı Öznitelikleri ve Talepleri'ni yapılandırarak güvenlik grupları için bir grup talebi ekleyin:

  • Source özniteliğini "Grup Kimliği" ve Ad Groups olarak ayarlayın (büyük harf 'G' ile tam olarak bu şekilde yazılır).

  • Ayrıca, talep yüklerini küçük tutmak ve Microsoft Entra ID'nin SAML onaylarında grup taleplerinin sayısını 150 ile sınırladığı sınırlamalarla karşılaşmamak için, taleplerde döndürülen grupları yalnızca açıkça atanan gruplarla sınırlamanızı kesinlikle öneririz:

    • "Talepte kullanıcıyla ilişkili hangi grupların döndürülmesi gerekiyor?" ifadesinin altında "Uygulamaya atanan gruplar" yanıtını verin. Ardından talep olarak eklemek istediğiniz gruplar için, "Kullanıcılar ve Gruplar" bölümünü kullanarak ve "Kullanıcı/grup ekle" seçeneğini belirleyerek bunları Kurumsal Uygulamaya atayın.

    

IAS'de:

• Kurumsal Kimlik Sağlayıcısı yapılandırmasında, Kimlik Federasyonu seçeneklerinin altında "Kimlik Doğrulaması kullanıcı depounu kullan" seçeneğini devre dışı bırakmanızdan emin olun; aksi takdirde Microsoft Entra Id'deki grup bilgileri SAML belirtecinde BTP'ye doğru korunmaz ve yetkilendirme başarısız olur.

BTP'de:

• Bu Alt Hesaptaki uygulamalar tarafından kullanılan Rol Koleksiyonları'nda IAS Kimlik Sağlayıcısı için bir yapılandırma ekleyerek ve Ad'ı Microsoft Entra grubunun Grup Kimliğine (Nesne Kimliği) ayarlayarak Rol Koleksiyonları'nı Kullanıcı Gruplarına eşleyin.

4 - Yalnızca benzer Kimlik gereksinimlerine sahip uygulamalar için tek bir BTP Alt Hesabı kullanın

Bağlam

BTP'de her Alt hesap birden çok uygulama içerebilir. Ancak, IAS açısından bakıldığında "Paketlenmiş Uygulama", içindeki daha ayrıntılı uygulamalar değil, eksiksiz bir BTP Alt Hesabıdır. Bu, IAS'deki tüm Güven ayarları, Kimlik Doğrulaması ve Erişim yapılandırmasının yanı sıra Marka ve Düzen seçeneklerinin söz konusu Alt Hesap içindeki tüm uygulamalar için geçerli olduğu anlamına gelir. Benzer şekilde, BTP'deki tüm Güven Yapılandırmaları ve Rol Koleksiyonları bu Alt hesaptaki tüm uygulamalar için de geçerlidir.

Ne öneriyoruz?

Birden çok uygulamayı tek bir BTP Alt Hesabı'nda birleştirmenizi ancak kimlik düzeyinde benzer gereksinimlere sahip olmaları (kullanıcılar, gruplar, kimlik sağlayıcıları, roller, güven yapılandırması, markalama, ...) öneririz.

Neden bu öneri?

Çok farklı kimlik gereksinimleri olan birden çok uygulamayı BTP'deki tek bir Alt hesapta birleştirerek, güvenli olmayan veya daha kolay yapılandırılabilir bir yapılandırma elde edebilirsiniz. Örneğin: BTP'de tek bir uygulama için kimlik sağlayıcısı gibi paylaşılan bir kaynakta yapılandırma değişikliği yapıldığında, bu durum bu paylaşılan kaynağı kullanan tüm uygulamaları etkiler.

Uygulamanın özeti

BTP'deki Alt Hesaplarda birden çok uygulamayı nasıl gruplandırmak istediğinizi dikkatle düşünün. Daha fazla bilgi için SAP Hesap Modeli belgelerine bakın.

5 - Tüm son kullanıcı Kimlik Doğrulaması ve Yetkilendirmesi için Üretim IAS kiracısını kullanın

Bağlam

IAS ile çalışırken genellikle bir Üretim ve Geliştirme/Test kiracınız olur. BTP'deki farklı Alt hesaplarda veya uygulamalarda, hangi kimlik sağlayıcısının (IAS kiracısı) kullanılacağını seçebilirsiniz.

Ne öneriyoruz?

Üretim IAS kiracısını, oturum açmaları gereken uygulamanın geliştirme/test sürümü veya ortamı bağlamında bile son kullanıcılarla her etkileşim için her zaman kullanmanızı öneririz.

Diğer IAS kiracılarını yalnızca Üretim kiracısından yalıtarak yapılması gereken kimlikle ilgili yapılandırmanın test edilmesi için kullanmanızı öneririz.

Neden bu öneri?

IAS, Microsoft Entra Kimliği ile federasyon için ayarlanmış merkezi bileşen olduğundan, federasyon ve kimlik yapılandırmasının ayarlanması ve korunması gereken tek bir yer vardır. Bunu diğer IAS kiracılarında çoğaltmak, ortamlar arasında son kullanıcı erişiminde yanlış yapılandırmalara veya tutarsızlıklara neden olabilir.

6 - SAML İmzalama Sertifikalarının Geçişi için bir İşlem Tanımlama

Bağlam

Microsoft Entra Id ile IAS arasında ve IAS ile BTP arasında federasyonu yapılandırırken, her iki taraf arasında gönderilen SAML belirteçlerinin şifreleme ve şifreleme imzaları için kullanılan X.509 sertifikalarını içeren SAML meta verileri değiştirilir. Bu sertifikaların son kullanma tarihleri vardır ve düzenli aralıklarla güncelleştirilmelidir (örneğin, bir sertifikanın gizliliğinin ihlal edildiği acil durumlarda bile).

Not: SAML onaylarını imzalamak için kullanılan ilk Microsoft Entra sertifikasının varsayılan geçerlilik süresi 3 yıldır (ve Microsoft Entra ID'de genel bir sertifika tarafından imzalanan OpenID Bağlan ve OAuth 2.0 belirteçlerinden farklı olarak sertifikanın Kurumsal Uygulamaya özgü olduğuna dikkat edin). Farklı bir son kullanma tarihine sahip yeni bir sertifika oluşturmayı veya kendi sertifikanızı oluşturup içeri aktarmayı seçebilirsiniz.

Sertifikaların süresi dolduğunda, bunlar artık kullanılamaz ve yeni sertifikaların yapılandırılması gerekir. Bu nedenle, sertifika yapılandırmasını bağlı olan taraf içinde (imzaların doğrulanması gerekir) SAML belirteçlerini imzalamak için kullanılan gerçek sertifikalarla güncel tutmak için bir işlem oluşturulmalıdır.

Bazı durumlarda, bağlı olan taraf bunu, en son meta veri bilgilerini dinamik olarak döndüren bir meta veri uç noktası sağlayarak otomatik olarak yapabilir; yani genellikle bağlı olan tarafın meta verileri düzenli aralıklarla alabildiği ve iç yapılandırma deposunu güncelleştirebileceği genel olarak erişilebilir bir URL.

Ancak IAS, Kurumsal Kimlik Sağlayıcılarının yalnızca meta veri XML dosyasını içeri aktarma yoluyla ayarlanmasına izin verir; Microsoft Entra meta verilerinin dinamik olarak alınması için bir meta veri uç noktası sağlanmasını desteklemez (örneğin https://login.microsoftonline.com/my-azuread-tenant/federationmetadata/2007-06/federationmetadata.xml?appid=my-app-id). Benzer şekilde, BTP IAS meta veri uç noktasından yeni bir Güven Yapılandırmasının ayarlanmasına izin vermez (örneğin https://my-ias-tenant.accounts.ondemand.com/saml2/metadata), meta veri XML dosyasının tek seferlik karşıya yüklenmesi gerekir.

Ne öneriyoruz?

İki sistem arasında kimlik federasyonu ayarlarken (örneğin, Microsoft Entra Id ve IAS'nin yanı sıra IAS ve BTP), kullanılan sertifikaların son kullanma tarihini yakaladığınıza emin olun. Bu sertifikaların önceden iyi değiştirilebildiğinden ve bu sertifikalara bağımlı olan tüm bağlı olan taraflarda yeni meta verileri güncelleştirmek için belgelenmiş bir işlem olduğundan emin olun.

Daha önce açıklandığı gibi, BTP'de IAS'ye yönelik bir güven yapılandırması ayarlamanızı öneririz. Bu yapılandırma da Kurumsal Kimlik Sağlayıcısı olarak Microsoft Entra Id ile federasyon olarak ayarlanır. Bu durumda, aşağıdaki sertifikalar (SAML imzalama ve şifreleme için kullanılır) önemlidir:

• BTP'deki Alt Hesap sertifikası: Bu değiştiğinde, IAS'deki Uygulamanın SAML 2.0 Yapılandırması güncelleştirilmelidir.
• IAS'deki kiracı sertifikası: Bu değiştiğinde, hem Kurumsal Uygulamanın Microsoft Entra Kimliği'ndeki SAML 2.0 Yapılandırması hem de BTP'deki Güven Yapılandırması güncelleştirilmelidir.
• Microsoft Entra Id'deki Kurumsal Uygulama sertifikası: Bu değiştiğinde, IAS'deki Kurumsal Kimlik Sağlayıcısı'nın SAML 2.0 Yapılandırması güncelleştirilmelidir.

SAP, SAP Bulut Tümleştirmesi ve süresi dolmakta olan işleme ile istemci sertifikası bildirimleri için örnek uygulamalara sahiptir. Bu, Azure Integration Services veya PowerAutomate ile uyarlanabilir. Ancak, sunucu sertifikalarıyla çalışmak için uyarlanması gerekir. Bu tür bir yaklaşım özel bir uygulama gerektirir.

Neden bu öneri?

Sertifikaların süresi dolmasına izin veriliyorsa veya zaman içinde değiştirildiğinde ancak bunlara bağlı olan bağlı olan taraflar yeni sertifika bilgileriyle güncelleştirilmezse, kullanıcılar artık federasyon aracılığıyla herhangi bir uygulamada oturum açamaz. Bu, meta verileri yeniden yapılandırarak hizmeti geri yüklerken tüm kullanıcılar için önemli bir kapalı kalma süresi anlamına gelebilir.

Uygulamanın özeti

Microsoft Entra Id'de sertifika süre sonu için bir e-posta bildirim adresi ekleyin ve tek bir kişiye gönderilmemesi için bir grup posta kutusuna ayarlayın (sertifikanın süresi dolmak üzere olduğunda bile hesabı olmayabilir). Varsayılan olarak, yalnızca Kurumsal Uygulamayı oluşturan kullanıcı bir bildirim alır.

Sertifika geçişi işleminin tamamını yürütmek için otomasyon oluşturmayı göz önünde bulundurun. Örneğin, süresi dolan sertifikaları düzenli aralıklarla denetleyebilen ve tüm bağlı olan tarafları yeni meta verilerle güncelleştirirken bunları değiştirebilirsiniz.

Kimlik Sağlayıcısı olarak Azure AD B2C kullanma

Azure Active Directory B2C , hizmet olarak işletmeden müşteriye kimlik sağlar. Azure AD B2C ile tümleştirmenin, kurumsal kullanıcıların Microsoft Entra ID ile oturum açmasına izin verdiğinize benzer olduğu düşünüldüğünde, yukarıdaki öneriler çoğunlukla müşterileriniz, tüketicileriniz veya vatandaşlarınız için Azure AD B2C kullanmak ve tercih ettikleri sosyal, kurumsal veya yerel hesap kimliklerini kullanmalarına izin vermek istediğinizde geçerlidir.

Ancak birkaç önemli fark vardır. Azure AD B2C'nin IAS'de kurumsal kimlik sağlayıcısı olarak ayarlanması ve her iki kiracı arasında federasyonun yapılandırılması bu blog gönderisinde daha ayrıntılı olarak açıklanmıştır.

Azure AD B2C'de SAML uygulaması kaydetme

Azure AD B2C'de IAS'de Kurumsal Kimlik Sağlayıcısı'na yönelik güven ilişkisini kolayca yapılandırmak için kullanabileceğiniz bir kurumsal uygulama galerisi yoktur. Bunun yerine, Bir SAML uygulamasını Azure AD B2C'ye kaydetmek için özel ilkeler kullanmanız gerekir. Bu SAML uygulaması, Microsoft Entra Id'deki kurumsal uygulamayla aynı mantıksal rolü oynar, bu nedenle SAML sertifikalarının geçişiyle ilgili aynı yönergeler geçerlidir, örneğin.

Azure AD B2C ile yetkilendirme

Azure AD B2C, erişim atayabileceğiniz kullanıcı koleksiyonları oluşturmak için grupların yerel olarak kullanılmasını desteklemez; bu da BTP'deki Rol Koleksiyonları aracılığıyla yetkilendirme için Microsoft Entra gruplarını kullanma kılavuzunun farklı şekilde uygulanması gerekir.

Neyse ki Azure AD B2C yüksek oranda özelleştirilebilir olduğundan IAS'ye gönderdiği SAML belirteçlerini özel bilgileri içerecek şekilde yapılandırabilirsiniz. Yetkilendirme taleplerini desteklemeyle ilgili çeşitli seçenekler için Azure AD B2C Uygulama Rolleri örneğine eşlik eden belgelere bakın, ancak özet olarak: API Bağlan veya genişletilebilirlik mekanizması aracılığıyla isteğe bağlı olarak kullanıcının neye erişmesine izin verileceğini belirlemek için grupları, uygulama rollerini ve hatta özel bir veritabanını kullanabilirsiniz.

Yetkilendirme bilgilerinin nereden geldiği fark etmeksizin, bu öznitelik adı talep şemasında varsayılan iş ortağı talep türü olarak yapılandırılarak veya çıkış taleplerinde iş ortağı talep türü geçersiz kılınarak SAML belirtecinin içinde öznitelik olarak Groups yayılabilir. Ancak BTP'nin Rol Koleksiyonlarını Kullanıcı Öznitelikleriyle eşlemenize izin verdiğine dikkat edin. Bu, öznitelik adını kullanmasanız Groups bile yetkilendirme kararları için herhangi bir öznitelik adının kullanılabileceğini gösterir.

Sonraki Adımlar

• Bu öğreticide ilk kurulum hakkında daha fazla bilgi edinin
• SAP kaynak ve hedef uygulamalarıyla kullanıcı sağlama için Microsoft Entra dağıtımı planlayın ve
• SAP uygulamalarınıza erişimi yönetme
• Microsoft Entra Id ve ötesi ile ek SAP tümleştirme senaryolarını keşfedin