Skenario - Menggunakan ID Microsoft Entra untuk mengamankan akses ke platform dan aplikasi SAP

Dokumen ini memberikan saran tentang desain teknis dan konfigurasi platform dan aplikasi SAP saat menggunakan MICROSOFT Entra ID sebagai layanan autentikasi pengguna utama untuk SAP Cloud Identity Services. SAP Cloud Identity Services mencakup Autentikasi Identitas, Provisi Identitas, Direktori Identitas, dan Manajemen Otorisasi. Pelajari selengkapnya tentang penyiapan awal untuk autentikasi dalam integrasi akses menyeluruh (SSO) Microsoft Entra dengan tutorial SAP Cloud Identity Services. Untuk informasi selengkapnya tentang provisi dan skenario lainnya, lihat merencanakan penyebaran Microsoft Entra untuk provisi pengguna dengan aplikasi sumber dan target SAP dan mengelola akses ke aplikasi SAP Anda.

Terminologi yang digunakan dalam panduan ini

Singkatan	Deskripsi
BTP	Platform Teknologi Bisnis SAP adalah platform inovasi yang dioptimalkan untuk aplikasi SAP di cloud. Sebagian besar teknologi SAP yang dibahas di sini merupakan bagian dari BTP. Produk yang secara resmi dikenal sebagai SAP Cloud Platform merupakan bagian dari SAP BTP.
IAS	SAP Cloud Identity Services - Autentikasi Identitas, komponen SAP Cloud Identity Services, adalah layanan cloud untuk autentikasi, akses menyeluruh, dan manajemen pengguna di cloud SAP dan aplikasi lokal. IAS membantu pengguna mengautentikasi ke instans layanan SAP BTP mereka sendiri, sebagai proksi yang terintegrasi dengan akses menyeluruh Microsoft Entra.
IPS	SAP Cloud Identity Services - Penyediaan Identitas, komponen SAP Cloud Identity Services, adalah layanan cloud yang membantu Anda memprovisikan identitas dan otorisasinya ke cloud SAP dan aplikasi lokal.
XSUAA	Layanan yang Diperpanjang untuk Akun dan Autentikasi Pengguna Cloud Foundry (Extended Services for Cloud Foundry User Account and Authentication). Cloud Foundry, platform as a service (PaaS) yang dapat disebarkan pada infrastruktur yang berbeda, adalah lingkungan tempat SAP membangun Platform Teknologi Bisnis SAP. XSUAA adalah server otorisasi OAuth multipenyewa yang merupakan komponen infrastruktur pusat dari lingkungan Cloud Foundry. XSUAA menyediakan autentikasi dan otorisasi pengguna bisnis dalam SAP BTP.
Fiori	Pengalaman pengguna berbasis web SAP (sebagai pengganti dari pengalaman berbasis desktop).

Gambaran Umum

Ada banyak layanan dan komponen dalam tumpukan teknologi SAP dan Microsoft yang berperan dalam skenario autentikasi dan otorisasi pengguna. Layanan utama tercantum dalam diagram di bawah ini.

Karena ada banyak permutasi kemungkinan skenario yang akan dikonfigurasi, kami fokus pada satu skenario yang sejalan dengan strategi pertama identitas Microsoft Entra. Kami akan membuat asumsi berikut:

• Anda ingin mengatur semua identitas Anda secara terpusat dan hanya dari ID Microsoft Entra.
• Anda ingin mengurangi upaya pemeliharaan sebanyak mungkin dan mengotomatisasi autentikasi dan akses aplikasi di seluruh Microsoft dan SAP.
• Panduan umum untuk MICROSOFT Entra ID dengan IAS berlaku untuk aplikasi yang disebarkan pada aplikasi BTP dan SAP SaaS yang dikonfigurasi di IAS. Rekomendasi khusus juga akan diberikan jika berlaku untuk BTP (misalnya, menggunakan pemetaan peran dengan grup Microsoft Entra) dan aplikasi SAP SaaS (misalnya, menggunakan layanan provisi identitas untuk otorisasi berbasis peran).
• Kami juga berasumsi bahwa pengguna sudah disediakan di MICROSOFT Entra ID dan terhadap sistem SAP apa pun yang mengharuskan pengguna untuk diprovisikan untuk berfungsi. Terlepas dari bagaimana hal itu dicapai: provisi dapat melalui secara manual, dari Active Directory lokal melalui Microsoft Entra Koneksi, atau melalui sistem SDM seperti SAP SuccessFactors. Oleh karena itu dalam dokumen ini, SuccessFactors dianggap sebagai aplikasi seperti yang lain di mana pengguna (yang sudah ada) akan masuk. Kami tidak mencakup provisi aktual pengguna dari SuccessFactors ke dalam ID Microsoft Entra. Untuk informasi selengkapnya tentang membawa pengguna ke ID Microsoft Entra untuk digunakan dengan beban kerja SAP, lihat rencana penyebaran Microsoft Entra untuk provisi pengguna dengan aplikasi sumber dan target SAP dan mengelola akses ke aplikasi SAP Anda.

Berdasarkan asumsi ini, kami berfokus terutama pada produk dan layanan yang disajikan dalam diagram di bawah ini. Berikut ini adalah berbagai komponen yang paling relevan dengan autentikasi dan otorisasi dalam lingkungan berbasis cloud.

Jika Anda telah menggunakan SAP Identity Management (IDM), maka Anda dapat memigrasikan skenario manajemen identitas dari SAP IDM ke Microsoft Entra. Untuk informasi selengkapnya, lihat Memigrasikan skenario manajemen identitas dari SAP IDM ke Microsoft Entra.

Catatan

Sebagian besar panduan yang ada di sini juga berlaku untuk Azure Active Directory B2C, namun ada beberapa perbedaan penting. Untuk informasi selengkapnya, lihat Menggunakan Azure AD B2C sebagai Penyedia Identitas.

Peringatan

Perhatikan batas pernyataan SAML SAP dan dampak panjang nama pengumpulan peran SAP Cloud Foundry dan jumlah koleksi yang diproksi oleh grup di SAP Cloud Identity Service. Untuk informasi selengkapnya, lihat catatan SAP 2732890 di SAP for Me. Batas terlampaui mengakibatkan masalah otorisasi.

Rekomendasi

Ringkasan

• 1 - Gunakan Autentikasi Terfederasi di Platform Teknologi Bisnis SAP dan aplikasi SAP SaaS melalui Layanan Autentikasi Identitas SAP
• 2 - Gunakan ID Microsoft Entra untuk Autentikasi dan IAS/BTP untuk Otorisasi
• 3 - Gunakan grup Microsoft Entra untuk Otorisasi melalui Koleksi Peran di IAS/BTP
• 4 - Gunakan Subaccount BTP tunggal hanya untuk aplikasi yang memiliki persyaratan Identitas serupa
• 5 - Gunakan penyewa Produksi IAS untuk semua Autentikasi dan Otorisasi pengguna akhir
• 6 - Tentukan Proses untuk Rollover Sertifikat Penandatanganan SAML

1 - Gunakan Autentikasi Terfederasi di Platform Teknologi Bisnis SAP dan aplikasi SAP SaaS melalui Layanan Autentikasi Identitas SAP

Konteks

Aplikasi Anda di BTP dapat menggunakan IdP melalui Konfigurasi Kepercayaan untuk mengautentikasi pengguna dengan menggunakan protokol SAML 2.0 antara BTP/XSUAA dan IdP. Perhatikan bahwa hanya SAML 2.0 yang didukung, meski protokol OpenID Connect digunakan antara aplikasi itu sendiri dan BTP/XSUAA (tidak relevan dalam konteks ini).

Di BTP, Anda dapat memilih untuk menyiapkan konfigurasi kepercayaan terhadap SAP Cloud Identity Services - Autentikasi Identitas (yang merupakan default) tetapi ketika direktori pengguna otoritatif Anda adalah ID Microsoft Entra, Anda dapat menyiapkan federasi sehingga pengguna dapat masuk dengan akun Microsoft Entra yang ada.

Selain federasi, Anda juga dapat menyiapkan provisi pengguna secara opsional sehingga pengguna Microsoft Entra disediakan di muka di BTP. Namun, tidak ada dukungan asli untuk ini (hanya untuk MICROSOFT Entra ID -> Layanan Autentikasi Identitas SAP); solusi terintegrasi dengan dukungan asli adalah Layanan Provisi Identitas BTP. Provisi akun pengguna di awal dapat berguna untuk tujuan otorisasi (misalnya, untuk menambahkan pengguna ke peran). Namun, tergantung pada persyaratan, Anda juga dapat mencapai ini dengan grup Microsoft Entra (lihat di bawah) yang dapat berarti Anda tidak memerlukan provisi pengguna sama sekali.

Saat menyiapkan hubungan federasi, terdapat beberapa opsi:

• Anda dapat memilih untuk melakukan federasi ke Microsoft Entra ID langsung dari BTP/XSUAA.
• Anda dapat memilih untuk bergabung dengan IAS yang pada gilirannya disiapkan untuk bergabung dengan ID Microsoft Entra sebagai Penyedia Identitas Perusahaan (juga dikenal sebagai "Proksi SAML").

Untuk aplikasi SAP SaaS, IAS disediakan dan dikonfigurasi sebelumnya untuk memudahkan onboarding pengguna akhir. (Contohnya termasuk SuccessFactors, Marketing Cloud, Cloud for Customer, Sales Cloud, dan lainnya.) Skenario ini kurang kompleks, karena IAS terhubung langsung dengan aplikasi target dan tidak diproksikan ke XSUAA. Bagaimanapun, aturan yang sama berlaku untuk penyiapan ini seperti untuk ID Microsoft Entra dengan IAS secara umum.

Apa yang menjadi rekomendasi kami?

Saat direktori pengguna otoritatif Anda adalah ID Microsoft Entra, sebaiknya siapkan konfigurasi kepercayaan di BTP menuju IAS. IAS pada gilirannya disiapkan untuk bergabung dengan ID Microsoft Entra sebagai Penyedia Identitas Perusahaan.

Pada konfigurasi kepercayaan di BTP, sebaiknya Anda mengaktifkan "Buat Pengguna Bayangan Selama Masuk". Dengan cara ini, pengguna yang belum dibuat di BTP, secara otomatis mendapatkan akun saat mereka masuk melalui IAS / Microsoft Entra ID untuk pertama kalinya. Jika pengaturan ini akan dinonaktifkan, hanya pengguna yang telah diprovisikan sebelumnya yang akan diizinkan untuk masuk.

Mengapa harus rekomendasi ini?

Saat menggunakan federasi, Anda dapat memilih untuk menentukan konfigurasi kepercayaan di tingkat Subaccount BTP. Dalam hal ini, Anda harus mengulangi konfigurasi untuk setiap Subaccount lain yang Anda gunakan. Dengan menggunakan IAS sebagai konfigurasi kepercayaan menengah, Anda mendapat manfaat dari konfigurasi terpusat di berbagai Subaccount dan Anda dapat menggunakan fitur IAS seperti Autentikasi berbasis risiko dan pengayaan atribut pernyataan terpusat. Untuk melindungi pengalaman pengguna, fitur keamanan canggih ini hanya boleh diberlakukan di satu lokasi. Ini bisa berupa IAS atau saat menyimpan ID Microsoft Entra sebagai penyimpanan pengguna otoritatif tunggal (seperti halnya premis makalah ini), ini akan ditangani secara terpusat oleh Microsoft Entra Conditional Access Management.

Catatan: untuk IAS, setiap Subaccount dianggap sebagai "aplikasi", meskipun terdapat satu atau lebih aplikasi yang dapat disebarkan dalam Subaccount tersebut. Dalam IAS, setiap aplikasi tersebut dapat disiapkan untuk federasi dengan IdP perusahaan yang sama (ID Microsoft Entra dalam hal ini).

Ringkasan implementasi

Di ID Microsoft Entra:

• Secara opsional mengonfigurasi ID Microsoft Entra untuk akses menyeluruh tanpa hambatan (Seamless SSO), yang secara otomatis memasukkan pengguna saat mereka berada di perangkat perusahaan mereka yang terhubung ke jaringan perusahaan Anda. Saat diaktifkan, pengguna tidak perlu mengetikkan kata sandi mereka untuk masuk ke Microsoft Entra ID, dan biasanya, bahkan mengetikkan nama pengguna mereka.

Di MICROSOFT Entra ID dan IAS:

• Ikuti dokumentasi untuk menyambungkan ID Microsoft Entra ke IAS dalam mode federasi (proksi) (dokumen SAP, dokumen Microsoft). NameID Perhatikan pengaturan pada konfigurasi SSO Anda di ID Microsoft Entra, karena UPN belum tentu alamat email.
• Konfigurasikan "Aplikasi Yang Dibundel" untuk menggunakan ID Microsoft Entra dengan masuk ke halaman "Autentikasi Bersyar" dan atur "Penyedia Identitas Autentikasi Default" ke Penyedia Identitas Perusahaan yang mewakili direktori Microsoft Entra Anda.

Di BTP:

• Siapkan konfigurasi kepercayaan terhadap IAS (SAP doc) dan pastikan bahwa baik "Tersedia untuk Masuk Pengguna” maupun "Buat Pengguna Bayangan Selama Masuk" diaktifkan.
• Secara opsional, nonaktifkan "Tersedia untuk Masuk Pengguna" pada konfigurasi kepercayaan "Layanan ID SAP" default sehingga pengguna selalu mengautentikasi melalui ID Microsoft Entra dan tidak disajikan dengan layar untuk memilih penyedia identitas mereka.

2 - Gunakan ID Microsoft Entra untuk Autentikasi dan IAS/BTP untuk Otorisasi

Konteks

Ketika BTP dan IAS telah dikonfigurasi untuk autentikasi pengguna melalui federasi menuju ID Microsoft Entra, ada beberapa opsi untuk mengonfigurasi otorisasi:

• Di ID Microsoft Entra, Anda dapat menetapkan pengguna dan grup Microsoft Entra ke Aplikasi Perusahaan yang mewakili instans IAS SAP Anda di ID Microsoft Entra.
• Di IAS, Anda dapat menggunakan Autentikasi Berbasis Risiko untuk mengizinkan atau memblokir proses masuk dan dengan itu mencegah akses ke aplikasi di BTP.
• Di BTP, Anda dapat menggunakan Koleksi Peran untuk menentukan pengguna dan grup mana yang dapat mengakses aplikasi dan mendapatkan peran tertentu.

Apa yang menjadi rekomendasi kami?

Kami menyarankan agar Anda tidak meletakkan otorisasi apa pun langsung di Microsoft Entra itu sendiri dan secara eksplisit menonaktifkan "Penugasan pengguna diperlukan" pada Aplikasi Perusahaan di ID Microsoft Entra. Perhatikan bahwa untuk aplikasi SAML, pengaturan ini diaktifkan secara default, jadi Anda harus mengambil tindakan eksplisit untuk menonaktifkannya.

Mengapa harus rekomendasi ini?

Ketika aplikasi digabungkan melalui IAS, dari sudut pandang MICROSOFT Entra ID, pengguna pada dasarnya "mengautentikasi ke IAS" selama alur masuk. Ini berarti bahwa ID Microsoft Entra tidak memiliki informasi tentang aplikasi BTP akhir mana yang coba digunakan pengguna untuk masuk. Itu juga menyiratkan bahwa otorisasi di MICROSOFT Entra ID hanya dapat digunakan untuk melakukan otorisasi yang sangat kasar, misalnya memungkinkan pengguna untuk masuk ke aplikasi apa pun di BTP, atau tidak ada. Hal ini juga menekankan strategi SAP untuk mengisolasi aplikasi dan mekanisme autentikasi pada tingkat Sub-akun BTP.

Meskipun itu bisa menjadi alasan yang valid untuk menggunakan "Penugasan pengguna yang diperlukan", itu berarti sekarang ada dua tempat yang berpotensi berbeda di mana informasi otorisasi perlu dipertahankan: baik di ID Microsoft Entra pada Aplikasi Perusahaan (di mana itu berlaku untuk semua aplikasi BTP), serta di setiap Subaccount BTP. Hal ini dapat menyebabkan kebingungan dan kesalahan konfigurasi di mana pengaturan otorisasi diperbarui di satu tempat tetapi tidak di tempat yang lain. Misalnya: pengguna diizinkan di BTP tetapi tidak ditetapkan ke aplikasi di ID Microsoft Entra yang mengakibatkan autentikasi gagal.

Ringkasan implementasi

Pada Aplikasi Microsoft Entra Enterprise yang mewakili hubungan federasi dengan IAS, nonaktifkan "Penugasan pengguna diperlukan". Ini juga berarti Anda dapat dengan aman melewatkan penugasan pengguna.

3 - Gunakan grup Microsoft Entra untuk Otorisasi melalui Koleksi Peran di IAS/BTP

Konteks

Ketika Anda ingin mengonfigurasi otorisasi untuk aplikasi BTP Anda, terdapat berbagai opsi:

• Anda dapat mengonfigurasi kontrol akses terperinci di dalam aplikasi itu sendiri, berdasarkan pengguna yang masuk.
• Anda dapat menentukan akses melalui Peran dan Koleksi Peran di BTP, berdasarkan penugasan pengguna atau penugasan grup.

Implementasi akhir dapat menggunakan kombinasi dari kedua strategi. Namun, untuk penugasan melalui Koleksi Peran, hal ini dapat dilakukan dengan basis pengguna per pengguna, atau seseorang dapat menggunakan grup IdP yang dikonfigurasi.

Apa yang menjadi rekomendasi kami?

Jika Anda ingin menggunakan MICROSOFT Entra ID sebagai sumber otoritatif untuk otorisasi terperintah, sebaiknya gunakan grup Microsoft Entra dan tetapkan ke Koleksi Peran di BTP. Memberikan pengguna akses ke aplikasi tertentu berarti menambahkannya ke grup Microsoft Entra yang relevan tanpa konfigurasi lebih lanjut yang diperlukan di IAS/BTP.

Dengan konfigurasi ini, sebaiknya gunakan ID Grup (ID Objek) grup Microsoft Entra sebagai pengidentifikasi unik grup, bukan nama tampilan ("sAMAccountName"). Ini berarti Anda harus menggunakan ID Grup sebagai pernyataan "Grup" dalam token SAML yang dikeluarkan oleh ID Microsoft Entra. Selain itu ID Grup digunakan untuk penugasan ke Koleksi Peran di BTP.

Mengapa harus rekomendasi ini?

Jika Anda akan menetapkan pengguna langsung ke Koleksi Peran di BTP, Anda tidak memusatkan keputusan otorisasi di ID Microsoft Entra. Ini juga berarti pengguna harus sudah ada di IAS sebelum mereka dapat ditugaskan ke Koleksi Peran di BTP - dan mengingat bahwa kami merekomendasikan federasi alih-alih provisi pengguna ini berarti akun bayangan pengguna mungkin belum ada di IAS pada saat Anda ingin melakukan penugasan pengguna. Menggunakan grup Microsoft Entra dan menetapkannya ke Koleksi Peran menghilangkan masalah ini.

Menetapkan grup ke Koleksi Peran mungkin tampaknya bertentangan dengan rekomendasi sebelumnya untuk tidak menggunakan ID Microsoft Entra untuk otorisasi. Namun dalam hal ini, keputusan otorisasi masih diambil di BTP, hanya saja keputusan sekarang didasarkan pada keanggotaan grup yang dipertahankan dalam ID Microsoft Entra.

Sebaiknya gunakan ID Grup grup Microsoft Entra daripada namanya karena ID Grup unik secara global, tidak dapat diubah dan tidak pernah dapat digunakan kembali untuk grup lain nanti; sedangkan menggunakan nama grup dapat menyebabkan masalah ketika nama diubah, dan ada risiko keamanan dalam menghapus grup dan satu lagi dibuat dengan nama yang sama tetapi dengan pengguna di dalamnya yang seharusnya tidak memiliki akses ke aplikasi.

Ringkasan implementasi

Di ID Microsoft Entra:

• Buat grup tempat pengguna dapat ditambahkan yang memerlukan akses ke aplikasi di BTP (misalnya, buat grup Microsoft Entra untuk setiap Kumpulan Peran di BTP).
• Pada Aplikasi Microsoft Entra Enterprise yang mewakili hubungan federasi dengan IAS, konfigurasikan Atribut Pengguna SAML & Klaim untuk menambahkan klaim grup untuk grup keamanan:

  • Tetapkan atribut Sumber ke "ID Grup" dan Nama ke Groups (eja persis seperti ini, dengan huruf besar 'G').

  • Selanjutnya, untuk menjaga payload klaim tetap kecil dan untuk menghindari keterbatasan di mana MICROSOFT Entra ID akan membatasi jumlah klaim grup hingga 150 dalam pernyataan SAML, kami sangat menyarankan untuk membatasi grup yang dikembalikan dalam klaim hanya untuk grup yang secara eksplisit ditetapkan:

    • Di bagian "Grup mana yang terkait dengan pengguna harus dikembalikan dalam klaim?" jawab dengan "Grup yang ditetapkan ke aplikasi". Kemudian untuk grup yang ingin Anda sertakan sebagai klaim, tetapkan ke Aplikasi Perusahaan menggunakan bagian "Pengguna dan Grup" dan pilih "Tambahkan pengguna/grup".

    

Dalam IAS:

• Pada konfigurasi Penyedia Identitas Perusahaan, di bawah opsi Federasi Identitas, pastikan Anda menonaktifkan "Gunakan penyimpanan pengguna Autentikasi Identitas"; jika tidak, informasi grup dari ID Microsoft Entra tidak akan dipertahankan dalam token SAML menuju BTP dan otorisasi akan gagal.

Catatan

Jika Anda perlu menggunakan penyimpanan pengguna Autentikasi Identitas (misalnya, untuk menyertakan klaim yang tidak dapat bersumber dari ID Microsoft Entra tetapi tersedia di penyimpanan pengguna IAS), Anda dapat mengaktifkan pengaturan ini. Namun, dalam hal ini, Anda harus mengonfigurasi Atribut Default yang dikirim ke aplikasi untuk menyertakan klaim yang relevan yang berasal dari ID Microsoft Entra (misalnya dengan ${corporateIdP.Groups} format ).

Di BTP:

• Pada Koleksi Peran yang digunakan oleh aplikasi di Subaccount tersebut, petakan Koleksi Peran ke Grup Pengguna dengan menambahkan konfigurasi untuk IdP IAS dan mengatur Nama ke ID Grup (ID Objek) grup Microsoft Entra.

Catatan

Jika Anda akan memiliki klaim lain di MICROSOFT Entra ID untuk berisi informasi otorisasi yang akan digunakan di BTP, Anda tidak perlu menggunakan Groups nama klaim. Inilah yang digunakan BTP saat Anda memetakan Koleksi Peran ke grup pengguna seperti di atas, tetapi Anda juga dapat memetakan Koleksi Peran ke Atribut Pengguna yang memberi Anda sedikit lebih banyak fleksibilitas.

4 - Gunakan Subaccount BTP tunggal hanya untuk aplikasi yang memiliki persyaratan Identitas serupa

Konteks

Dalam BTP, setiap Subaccount dapat berisi beberapa aplikasi. Namun, dari sudut pandang IAS "Aplikasi Bundel" adalah Subaccount BTP yang lengkap, bukan aplikasi yang lebih terperinci di dalamnya. Ini berarti bahwa semua pengaturan Kepercayaan, Autentikasi, dan Konfigurasi akses serta opsi Branding dan Tata Letak di IAS berlaku untuk semua aplikasi dalam Subaccount tersebut. Demikian pula, semua Konfigurasi Kepercayaan dan Koleksi Peran di BTP juga berlaku untuk semua aplikasi dalam Subaccount tersebut.

Apa yang menjadi rekomendasi kami?

Sebaiknya Anda menggabungkan beberapa aplikasi dalam satu Subaccount BTP hanya jika mereka memiliki persyaratan serupa pada tingkat identitas (pengguna, grup, IdP, peran, konfigurasi kepercayaan, branding, ...).

Mengapa harus rekomendasi ini?

Dengan menggabungkan beberapa aplikasi yang memiliki persyaratan identitas yang sangat berbeda ke dalam satu Subaccount di BTP, Anda bisa berakhir dengan konfigurasi yang tidak aman atau rentan mengalami kesalahan konfigurasi. Misalnya: ketika konfigurasi berubah menjadi sumber daya bersama seperti IdP dibuat untuk satu aplikasi di BTP, hal ini memengaruhi semua aplikasi yang mengandalkan sumber daya bersama ini.

Ringkasan implementasi

Hati-hati mempertimbangkan bagaimana Anda ingin mengelompokkan beberapa aplikasi di Subaccount di BTP. Untuk informasi selengkapnya, lihat dokumentasi Model Akun SAP.

5 - Gunakan penyewa Produksi IAS untuk semua Autentikasi dan Otorisasi pengguna akhir

Konteks

Saat bekerja dengan IAS, Anda biasanya memiliki penyewa Produksi dan Dev/Test. Untuk Subaccount atau aplikasi yang berbeda di BTP, Anda dapat memilih IdP mana (penyewa IAS) yang akan digunakan.

Apa yang menjadi rekomendasi kami?

Sebaiknya selalu gunakan penyewa Produksi IAS untuk interaksi apa pun dengan pengguna akhir, bahkan dalam konteks versi dev/test atau lingkungan aplikasi yang harus mereka masuki.

Sebaiknya gunakan penyewa IAS lainnya hanya untuk pengujian konfigurasi terkait identitas, yang harus dilakukan secara terpisah dari penyewa Produksi.

Mengapa harus rekomendasi ini?

Karena IAS adalah komponen terpusat yang telah disiapkan untuk digabungkan dengan ID Microsoft Entra, hanya ada satu tempat di mana konfigurasi federasi dan identitas harus disiapkan dan dikelola. Menduplikasi ini di penyewa IAS lainnya dapat menyebabkan kesalahan konfigurasi atau inkonsistensi dalam akses pengguna akhir antar lingkungan.

6 - Tentukan Proses untuk Rollover Sertifikat Penandatanganan SAML

Konteks

Saat mengonfigurasi federasi antara MICROSOFT Entra ID dan IAS, serta antara IAS dan BTP, metadata SAML ditukar yang berisi sertifikat X.509 yang digunakan untuk enkripsi dan tanda tangan kriptografi token SAML yang dikirim antara kedua belah pihak. Sertifikat ini memiliki tanggal kedaluwarsa dan harus diperbarui secara berkala (bahkan dalam situasi darurat ketika sertifikat sedang rentan misalnya).

Catatan: periode validitas default sertifikat Microsoft Entra awal yang digunakan untuk menandatangani pernyataan SAML adalah 3 tahun (dan perhatikan bahwa sertifikat khusus untuk Aplikasi Perusahaan, tidak seperti token OpenID Koneksi dan OAuth 2.0 yang ditandatangani oleh sertifikat global di ID Microsoft Entra). Anda dapat memilih untuk membuat sertifikat baru dengan tanggal kedaluwarsa yang berbeda, atau membuat dan mengimpor sertifikat Anda sendiri.

Ketika sertifikat kedaluwarsa, mereka tidak dapat lagi digunakan, dan sertifikat baru harus dikonfigurasikan. Oleh karena itu, suatu proses harus dibuat untuk menjaga konfigurasi sertifikat di dalam pihak yang mengandalkan (yang perlu memvalidasi tanda tangan) tetap terkini dengan sertifikat aktual yang digunakan untuk menandatangani token SAML.

Dalam beberapa kasus, pihak yang mengandalkan dapat melakukan ini secara otomatis dengan menyediakannya dengan titik akhir metadata yang mengembalikan informasi metadata terbaru secara dinamis - yaitu, biasanya URL yang dapat diakses publik tempat pihak yang mengandalkan dapat secara berkala mengambil metadata dan memperbarui penyimpanan konfigurasi internalnya.

Namun, IAS hanya memungkinkan Penyedia Identitas Perusahaan untuk disiapkan melalui impor file XML metadata, ia tidak mendukung penyediaan titik akhir metadata untuk pengambilan dinamis metadata Microsoft Entra (misalnya https://login.microsoftonline.com/my-azuread-tenant/federationmetadata/2007-06/federationmetadata.xml?appid=my-app-id). Demikian pula, BTP tidak mengizinkan Konfigurasi Kepercayaan baru untuk disiapkan dari titik akhir metadata IAS (misalnya https://my-ias-tenant.accounts.ondemand.com/saml2/metadata), dan juga memerlukan pengunggahan satu kali file XML metadata.

Apa yang menjadi rekomendasi kami?

Saat menyiapkan federasi identitas antara dua sistem apa pun (misalnya, ID Microsoft Entra dan IAS serta IAS dan BTP), pastikan Anda mengambil tanggal kedaluwarsa sertifikat yang digunakan. Pastikan sertifikat ini dapat diganti jauh sebelumnya, dan bahwa ada proses yang terdokumentasi untuk memperbarui metadata baru di semua pihak yang mengandalkan yang bergantung pada sertifikat ini.

Seperti yang dibahas sebelumnya, sebaiknya siapkan konfigurasi kepercayaan di BTP terhadap IAS, yang pada gilirannya disiapkan untuk bergabung dengan ID Microsoft Entra sebagai Penyedia Identitas Perusahaan. Dalam hal ini, sertifikat berikut (yang digunakan untuk penandatanganan dan enkripsi SAML) bersifat penting:

• Sertifikat Subaccount di BTP: ketika hal ini berubah, Konfigurasi SAML 2.0 Aplikasi di IAS harus diperbarui.
• Sertifikat penyewa di IAS: ketika ini berubah, Konfigurasi SAML 2.0 Aplikasi Perusahaan di ID Microsoft Entra dan Konfigurasi Kepercayaan di BTP harus diperbarui.
• Sertifikat Aplikasi Perusahaan di ID Microsoft Entra: ketika ini berubah, Konfigurasi SAML 2.0 Penyedia Identitas Perusahaan di IAS harus diperbarui.

SAP memiliki contoh implementasi untuk pemberitahuan sertifikat klien dengan Integrasi Cloud SAP dan penanganan yang hampir kedaluwarsa. Hal ini dapat disesuaikan dengan Azure SSIS atau PowerAutomate. Namun, mereka perlu disesuaikan untuk bekerja dengan sertifikat server. Pendekatan seperti itu membutuhkan implementasi kustom.

Mengapa harus rekomendasi ini?

Jika sertifikat diizinkan untuk kedaluwarsa, atau ketika mereka diganti tepat waktu tetapi pihak-pihak yang mengandalkan yang bergantung pada mereka tidak diperbarui dengan informasi sertifikat baru, pengguna tidak akan lagi dapat masuk ke aplikasi apa pun melalui federasi. Ini dapat berarti waktu henti yang signifikan untuk semua pengguna saat Anda memulihkan layanan dengan mengonfigurasi ulang metadata.

Ringkasan implementasi

Tambahkan alamat pemberitahuan email untuk kedaluwarsa sertifikat di ID Microsoft Entra dan atur ke kotak surat grup sehingga tidak dikirim ke satu individu (yang bahkan mungkin tidak lagi memiliki akun pada saat sertifikat akan kedaluwarsa). Secara default, hanya pengguna yang membuat Aplikasi Enterprise yang akan menerima pemberitahuan.

Pertimbangkan untuk membangun otomatisasi untuk mengeksekusi seluruh proses pembaruan sertifikat. Misalnya, seseorang dapat secara berkala memeriksa sertifikat yang kedaluwarsa dan menggantinya sambil memperbarui semua pihak yang mengandalkan dengan metadata baru.

Menggunakan Azure Active Directory B2C sebagai Penyedia Identitas

Azure Active Directory B2C memberikan identitas bisnis-ke-pelanggan sebagai layanan. Mengingat bahwa integrasi dengan Azure AD B2C mirip dengan bagaimana Anda akan mengizinkan pengguna perusahaan untuk masuk dengan MICROSOFT Entra ID, rekomendasi di atas sebagian besar masih berlaku ketika Anda ingin menggunakan Azure AD B2C untuk pelanggan, konsumen, atau warga negara Anda dan memungkinkan mereka menggunakan identitas sosial, perusahaan, atau akun lokal pilihan mereka.

Namun, ada beberapa perbedaan penting. Menyiapkan Azure AD B2C sebagai penyedia identitas perusahaan di IAS dan mengonfigurasi federasi antara kedua penyewa dijelaskan secara lebih rinci dalam posting blog ini.

Mendaftarkan aplikasi SAML di Azure Active Directory B2C

Azure Active Directory B2C tidak memiliki galeri aplikasi perusahaan yang dapat Anda gunakan untuk dengan mudah mengonfigurasi hubungan kepercayaan terhadap Penyedia Identitas Perusahaan di IAS. Sebagai gantinya, Anda harus menggunakan kebijakan kustom untuk mendaftarkan aplikasi SAML di Azure Active Directory B2C. Aplikasi SAML ini memainkan peran logis yang sama dengan aplikasi perusahaan di ID Microsoft Entra, sehingga panduan yang sama seputar rollover sertifikat SAML berlaku, misalnya.

Otorisasi dengan Azure Active Directory B2C

Azure AD B2C tidak secara asli mendukung penggunaan grup untuk membuat koleksi pengguna yang dapat Anda tetapkan aksesnya, yang berarti bahwa panduan untuk menggunakan grup Microsoft Entra untuk otorisasi melalui Koleksi Peran di BTP harus diterapkan secara berbeda.

Untungnya, Azure Active Directory B2C sangat dapat disesuaikan, sehingga Anda dapat mengonfigurasi token SAML yang dikirim ke IAS untuk menyertakan informasi kustom apa pun. Untuk berbagai opsi tentang mendukung klaim otorisasi, lihat dokumentasi yang menyertai contoh Peran Aplikasi Azure Active Directory B2C, namun secara ringkas: melalui mekanisme ekstensibilitas Konektor API Anda masih dapat menggunakan grup, aplikasi peran, atau bahkan database kustom untuk menentukan apa yang boleh diakses pengguna.

Terlepas dari mana informasi otorisasi berasal, informasi tersebut kemudian dapat dikeluarkan sebagai atribut Groups di dalam token SAML dengan mengonfigurasi nama atribut tersebut sebagai jenis klaim mitra default pada skema klaim atau dengan mengganti jenis klaim mitra pada klaim output. Namun perhatikan bahwa BTP memungkinkan Anda memetakan Koleksi Peran ke Atribut Pengguna, yang berarti bahwa setiap nama atribut dapat digunakan untuk keputusan otorisasi, meskipun Anda tidak menggunakan nama atribut Groups.

Langkah berikutnya

• Pelajari selengkapnya tentang penyiapan awal dalam tutorial ini
• rencana penyebaran Microsoft Entra untuk provisi pengguna dengan aplikasi sumber dan target SAP dan
• mengelola akses ke aplikasi SAP Anda
• Menemukan skenario integrasi SAP tambahan dengan ID Microsoft Entra dan seterusnya