Ketika saya mendengar seseorang mengatakan bahwa mereka telah “memodernisasi” sebuah aplikasi, itu biasanya berarti mereka telah mengaktifkan SAML atau OIDC. Mungkin keduanya.
Sangatmelakukanmenyederhanakan akses dan mengurangi gesekan.Tapi inilah yang mengkhawatirkan saya: terlalu banyak tim berhenti di sana.Mereka menerapkan SSO dan mengasumsikan bagian yang sulit telah berakhir.
Mengapa “kami modernisasi” tidak selalu berarti apa yang Anda pikirkan
Ketika orang-orang memberi tahu saya bahwa aplikasi mereka telah dimodernisasi, saya bertanya apa artinya. Dalam banyak kasus, itu hanya berarti bahwa aplikasi sekarang mendukung SSO. masih menggunakan logika sesi internal yang sama. otorisasi masih dikodekan dalam-dalam aplikasi. itu masih rapuh - hanya dengan halaman login yang lebih baik.
Apa yang terjadi di sini lebih umum daripada kebanyakan mengakui: kita memodernisasi pintu depan dan meninggalkan sisa rumah tidak berubah.
Dan itu adalah masalah, karena identitas tidak hanya tentang masuk, itu tentang apa yang terjadi setelahnya.
Apa yang sebenarnya autentikasi modern memberikan
Protokol auth modern seperti SAML dan OIDC dirancang untuk memecahkan tantangan nyata – terutama login dan federasi.
Itu adalah kemajuan nyata. dan ya, SSO melalui protokol ini meningkatkan postur keamanan. tetapi mari kita tidak membingungkan kenyamanan dengan kelengkapan.
Protokol adalah kemajuan - tetapi mereka bukan garis akhir
Jangan salah, menambahkan dukungan untuk OIDC atau SAML adalah kemajuan. Anda mendapatkan kata sandi yang lebih sedikit, kurang gesekan, dan pengalaman pengguna yang lebih konsisten. Apa yang mereka tidak menyediakan adalah kontrol kritis lainnya yang kami mengandalkan dengan sistem Manajemen Akses Web (WAM): kontrol sesi terpusat, penegakan otorisasi, integrasi direktori, dan pengolahan kebijakan yang konsisten.
Sistem WAM tidak sempurna, tetapi mereka memberi kami lapisan kontrol yang konsisten di seluruh aplikasi.Ketika kami menghapusnya tanpa mengganti lapisan itu, kami kehilangan sesuatu yang penting - dan saya telah melihat konsekuensi dari tangan pertama.
Aplikasi tidak modern jika identitas masih hard-coded
Saya telah melihat aplikasi yang terlihat ramping di permukaan tetapi masih bergantung pada identitas yang rapuh dan spesifik pengembang yang mengalir di balik adegan. dalam kasus ini, menambahkan SSO tidak menangani risiko nyata - perilaku yang tidak konsisten di seluruh aplikasi dan lingkungan.
Beberapa tim masih menggunakan pustaka sesi yang sudah usang. yang lain mengkode aturan akses dengan cara yang membuat audit menjadi mimpi buruk.
Di mana hal-hal jatuh: manajemen sesi
Salah satu titik buta identitas terbesar di lingkungan modern adalah manajemen sesi. orang menganggap SSO mengurusnya, tetapi tidak.
Dengan WAM, perilaku sesi – timeout, perpanjangan waktu, penangguhan – ditangani di satu tempat. Anda dapat menerapkan perubahan kebijakan dan tahu itu akan berlaku di seluruh perusahaan. Hari ini, logika sesi tertanam di dalam setiap aplikasi individu, tersebar di berbagai bahasa dan kerangka kerja.
Saya telah bekerja dengan tim menggunakan Spring, Node.js, Rails — dan bahkan dalam satu kerangka kerja, tidak ada jaminan konsistensi.
Tidak dapat memaksakan waktu sesi yang konsisten adalah risiko besar jika mereka tidak dapat membatalkan sesi ketika sesuatu yang mencurigakan terjadi.
Biaya dari Decentralized Session Logic
Ketika memperbaiki pustaka sesi memakan waktu berminggu-minggu atau berbulan-bulan, atau tidak ada yang tahu di mana timeout kosong didefinisikan, keamanan menjadi responsif pada saat terbaik.
Ini bukan teori. saya telah melihat perusahaan berjuang hanya untuk melacak bagaimana pengolahan sesi mereka bahkan bekerja. itu telah menjadi pengetahuan suku, tersembunyi dalam kode aplikasi.
Itu tidak berkelanjutan – terutama untuk perusahaan yang berurusan dengan kepatuhan atau tujuan Zero Trust.
Identity Spread dan Authorization Drift
Hal yang sama yang terjadi dengan logika sesi terjadi dengan otorisasi.Setelah didorong ke bawah ke kode aplikasi, menjadi hampir mustahil untuk mengelola secara sentral.
Aturan terkubur dalam logika bisnis. Kebijakan bergeser. Dan pada akhirnya, tidak ada yang tahu persis siapa yang memiliki akses ke apa — atau mengapa. bahkan aplikasi yang mendukung otentikasi modern dapat gagal di sini, karena AuthZ bukan bagian dari protokol.
Orkestrasi harus datang selanjutnya
Pada titik ini, saya pikir jelas: otentikasi modern hanya satu bagian dari teka-teki.
Keuntungan menggunakan orchestration meliputi:
- Mengembalikan kemampuan untuk membatalkan sesi segera
- Menerapkan kebijakan sesi dan authZ secara konsisten
- Mengelola kunci federasi dan certs dari satu tempat
- Integrasi dengan sinyal risiko (seperti CAEP) untuk mendukung Zero Trust
- Dan melakukannya semua tanpa menulis ulang aplikasi atau beralih penyedia identitas
Orkestrasi menutup kesenjangan antara “support protokol modern” dan modernisasi identitas nyata.
Centralisasi tidak berarti mundur
Kadang-kadang orang mengasumsikan bahwa membawa kontrol identitas kembali ke satu tempat adalah langkah mundur.
Ini tentang memungkinkan kelincahan. tentang memberikan tim keamanan visibilitas yang mereka butuhkan tanpa memperlambat pengembang. tentang mengelola identitas sebagai layanan - bukan sebagai serangkaian hack khusus aplikasi.
Ketika Anda tidak memiliki orkestrasi, setiap tantangan identitas menjadi solusi satu kali.
Jika saya berbicara dengan tim keamanan, saya biasanya akan mengajukan pertanyaan seperti ini: “Berapa cepat Anda bisa membatalkan sesi pengguna?Melalui setiap aplikasi di perusahaan AndaSekarang saja?”
Jika jawabannya kurang dari “sekarang”, ada masalah yang layak diselesaikan.
The takeaway: jangan berhenti di SSO
Saya akan mengatakannya dengan jelas: otentikasi modern sangat penting, tetapi tidak lengkap.Jika Anda berhenti di SSO, Anda kehilangan lapisan kontrol yang membuat segalanya bekerja - aman, konsisten, dan berskala.
Jadi ya, adopsi SAML. Roll out OIDC. Tapi jangan biarkan kotak login menjadi garis akhir. SSO dan SAML saja tidak membuat
Jika Anda ingin keamanan nyata, orkestrasi harus menjadi bagian dari perjalanan.
Tentang Penulis
Darren Platt telah memimpin tim rekayasa di Securant Technologies, Ping Identity, Simplified, RSA, dan Oracle. sekarang dia adalah VP Manajemen Produk dan Rekayasa di Strata Identity, di mana dia membangun platform Distributed Identity Orchestration pertama untuk lingkungan yang didistribusikan dan berkontribusi pada standar pengoreksian kebijakan baru, IDQL dan perangkat lunak referensi Hexa.
