Selama bertahun-tahun Active Directory Federation Services, atau ADFS, telah berfungsi sebagai jembatan identitas yang tangguh yang menghubungkan sumber daya lokal ke cloud. Saat ini arah strategis Microsoft semakin terpusat pada Azure AD, yang sekarang diberi merek sebagai Microsoft Entra ID, sebagai platform identitas utamanya.

Meskipun ADFS tetap didukung, fokus pengembangan jangka panjangnya jelas menjadi sekunder dibandingkan Entra ID, yang kini mewakili layanan identitas inti Microsoft.
Pergeseran ini menghadirkan tantangan signifikan bagi banyak organisasi besar, terutama di sektor pendidikan dan penelitian yang mengandalkan Shibboleth IdP untuk mengelola akses federasi. Bagi mereka, migrasi bukanlah latihan angkat dan pindah yang sederhana. Transisi yang sukses memerlukan perencanaan yang matang untuk mempertahankan Single Sign On SSO yang berkelanjutan dan memastikan aliran atribut yang benar di antara sistem identitas yang kompleks ini.
Panduan ini memberikan peta jalan yang jelas untuk memigrasikan aplikasi dari ADFS ke Azure AD. Kami fokus secara khusus pada menavigasi transisi ini sambil tetap berdampingan dengan, atau bertransisi sepenuhnya dari, lingkungan Shibboleth IdP.
Mengapa Migrasi Semakin Diperlukan: Manfaat Identitas Modern (Entra ID)
Langkah menjauh dari ADFS sebagian besar didorong oleh peningkatan efisiensi operasional, kapabilitas keamanan, dan fleksibilitas tata kelola. Bagi banyak organisasi, ini merupakan kemajuan strategis menuju manajemen identitas yang lebih tangguh.
- Pengurangan Biaya dan Kerumitan: ADFS memerlukan server fisik atau virtual, manajemen sertifikat yang berkelanjutan, penambalan perangkat lunak, dan pemantauan infrastruktur. Azure AD atau Entra ID adalah layanan berbasis cloud, mengurangi ketergantungan infrastruktur dan mengalihkan tanggung jawab pemeliharaan platform ke Microsoft. Hal ini memungkinkan tim internal untuk lebih fokus pada inisiatif strategis daripada pemeliharaan server.
- Keamanan dan Kepatuhan yang Ditingkatkan: Azure AD menyediakan kapabilitas keamanan modern bawaan termasuk kebijakan Akses Bersyarat, kontrol akses terperinci, dan dukungan untuk Multi-Factor Authentication MFA yang tahan terhadap phishing. Meskipun beberapa kontrol ini dapat diimplementasikan dalam ADFS, mereka lebih terintegrasi secara asli dan dikelola secara terpusat di dalam Entra ID. Oleh karena itu, migrasi dapat meningkatkan visibilitas dan kontrol atas risiko berbasis identitas.
- Faktor Shibboleth: Migrasi juga menghadirkan peluang untuk menilai kembali kerumitan arsitektur. Organisasi yang mengoperasikan lingkungan Shibboleth IdP dan ADFS sering kali mengakumulasi konfigurasi federasi berlapis dari waktu ke waktu. Dengan merancang ulang aliran identitas di sekitar pola federasi modern, dimungkinkan untuk menyederhanakan hubungan kepercayaan dan mengurangi ketergantungan pada konfigurasi relai lama. Hasilnya sering kali berupa arsitektur identitas yang lebih bersih dan lebih mudah dikelola.
Tiga Fase Migrasi yang Sukses
Fase 1: Penemuan dan Penilaian
Fase tunggal yang paling kritis dari migrasi apa pun adalah penemuan. Anda tidak dapat memindahkan apa yang tidak Anda pahami sepenuhnya. Lingkungan ADFS Anda menyimpan konfigurasi dan kerumitan yang terakumulasi selama bertahun-tahun.
Mulailah dengan menyusun inventaris lengkap dari semua Relying Party Trusts RPTs yang saat ini dikonfigurasi pada server ADFS Anda. RPT ini mewakili setiap aplikasi, layanan eksternal, dan mitra pihak ketiga yang bergantung pada ADFS untuk autentikasi. Perhatikan baik-baik RPT yang mengamankan akses ke sumber daya Shibboleth internal Anda, karena ini mungkin memerlukan pertimbangan tambahan selama migrasi.
Microsoft menyediakan beberapa alat untuk membantu proses penemuan ini. Sebagai contoh, dasbor migrasi aplikasi ADFS yang tersedia di dalam pusat admin Microsoft Entra dapat membantu organisasi meninjau konfigurasi Relying Party Trust yang ada dan mengidentifikasi aplikasi yang mungkin memerlukan analisis lebih lanjut sebelum migrasi.
Namun, lingkungan dengan aturan klaim yang disesuaikan atau konfigurasi non-standar sering kali memerlukan tinjauan manual tambahan. Fase penilaian ini pada akhirnya menentukan cakupan dan garis waktu proyek migrasi.
Fase 2: Migrasi Aplikasi dan Pengujian
Setelah dinilai, aplikasi harus dimigrasikan dalam gelombang yang terkontrol. Salah satu tantangan teknis paling signifikan dalam migrasi ADFS melibatkan kepastian aliran data identitas yang benar, yang biasa disebut sebagai klaim dan atribut.
ADFS menggunakan Aturan Klaim untuk menentukan atribut pengguna mana yang dilepaskan ke aplikasi tertentu. Selama migrasi, aturan ini harus dipetakan dengan hati-hati ke konfigurasi klaim token Azure AD. Titik kegagalan umum di lingkungan yang juga menggunakan Shibboleth adalah penanganan keanggotaan grup atau atribut khusus pendidikan yang salah yang diperlukan oleh layanan federasi.
Terapkan strategi uji coba dan jalankan secara paralel. Hindari memigrasikan semua aplikasi secara bersamaan. Konfigurasikan aplikasi di Azure AD atau Entra ID sambil tetap menjalankan instansi ADFS secara paralel. Uji dengan sekelompok kecil pengguna menggunakan konfigurasi Azure AD baru sebelum mentransisikan akses untuk organisasi yang lebih luas.
Pengujian menyeluruh harus mengonfirmasi bahwa pengguna dapat berhasil melakukan autentikasi dan bahwa aplikasi menerima atribut yang benar yang diperlukan untuk otorisasi.
Fase 3: Pengalihan dan Tata Kelola
Fase terakhir melibatkan transisi aplikasi ke platform identitas baru dan penghentian infrastruktur ADFS lama secara bertahap. Setelah pengujian percontohan berhasil, aplikasi dapat diperbarui untuk mengarah sepenuhnya ke konfigurasi Azure AD yang baru.
Jika organisasi memigrasikan seluruh model autentikasi penggunanya, konfigurasi identitas mungkin perlu disesuaikan dari model autentikasi federasi ke pendekatan autentikasi terkelola atau cloud. Di banyak lingkungan, ini melibatkan pembaruan konfigurasi Azure AD Connect sehingga Azure AD menjadi otoritas autentikasi utama daripada mengandalkan ADFS.
Tata kelola pasca-migrasi sama pentingnya. Pastikan pencatatan audit yang tepat diaktifkan di dalam Azure AD dan tetapkan proses pemantauan untuk melacak aktivitas autentikasi, pola akses yang tidak terduga, atau masalah klaim atribut yang mungkin muncul dalam beberapa minggu setelah pengalihan.

Menjembatani Celah Shibboleth: Menyelesaikan Tantangan Login Ganda
Meskipun peralihan dari ADFS ke Azure AD menyelesaikan banyak tantangan operasional, hal itu dapat menimbulkan frustrasi baru bagi organisasi yang menjalankan lingkungan identitas campuran. Pengguna mungkin mendapati diri mereka harus login ke sumber daya Shibboleth dan sumber daya Azure AD secara terpisah. Pengalaman login ganda ini merusak tujuan dari Single Sign On dan dapat menciptakan hambatan bagi pengguna serta tambahan permintaan ke pusat bantuan layanan.
Tantangan ini muncul dari berbagai cara kedua penyedia identitas ini mengelola sesi dan token autentikasi. Tanpa mekanisme untuk menghubungkan kedua lingkungan tersebut, pengguna mungkin diharuskan untuk melakukan autentikasi lagi saat berpindah antara aplikasi penelitian federasi yang diamankan oleh Shibboleth dan aplikasi korporat yang diamankan oleh Azure AD.
Dalam lingkungan seperti ini, konfigurasi tambahan atau alat khusus sering kali diperlukan untuk menghubungkan alur autentikasi antara kedua penyedia tersebut. Salah satu pendekatannya adalah penggunaan mekanisme jembatan yang membantu menyinkronkan sesi autentikasi antar sistem identitas.
Overt Software Solutions mengembangkan jembatan SAAM (Shibboleth ADFS/Azure AD Authentication Module) untuk mendukung jenis integrasi ini. Jembatan SAAM memungkinkan autentikasi dari satu lingkungan untuk dikenali oleh lingkungan lainnya, membantu organisasi memberikan pengalaman Single Sign On yang lebih konsisten di seluruh sumber daya Shibboleth dan Azure AD.
Anda dapat mempelajari lebih lanjut tentang jembatan SAAM dan kemampuan autentikasi silangnya di situs web Overt Software Solutions atau hanya dengan menekan tombol di bawah ini:

Mencapai Ketangguhan Identitas Modern: Jalur Aman Anda Menuju Entra ID
Migrasi dari ADFS ke Azure AD merupakan langkah penting bagi banyak organisasi yang menginginkan peningkatan keamanan, pengurangan biaya operasional infrastruktur, dan akses ke kapabilitas identitas modern.
Namun, proses migrasi dapat menjadi rumit, dan risiko kesalahan konfigurasi meningkat di lingkungan yang bergantung pada Shibboleth atau sistem identitas federasi lainnya. Keberhasilan mengelola transisi sambil mengatasi tantangan login ganda memerlukan perencanaan yang matang, pengujian menyeluruh, dan alat integrasi yang tepat.
Tim di Overt Software Solutions memberikan panduan spesialis untuk mendukung organisasi selama migrasi dari ADFS ke Azure AD. Kami bekerja dengan institusi yang mengoperasikan lingkungan identitas yang kompleks, termasuk mereka yang menggunakan Shibboleth IdP untuk akses federasi.
Layanan kami membantu organisasi mengelola pemetaan atribut, integrasi identitas, dan perencanaan migrasi di seluruh lingkungan Azure AD dan Shibboleth. Jembatan SAAM yang dikembangkan oleh Overt Software Solutions dirancang untuk membantu organisasi menghubungkan autentikasi antara sistem-sistem ini dan mengurangi hambatan dari pengalaman login ganda.
Jika Anda merencanakan migrasi dari ADFS ke Entra ID dan ingin memastikan proses tersebut dikelola dengan cermat, tim di Overt Software Solutions dapat membantu memandu transisi Anda.
Hubungi Overt Software Solutions hari ini untuk memastikan transisi yang sukses dan tangguh ke Microsoft Entra ID.
