Bagaimana Anda merancang layanan penyediaan SCIM 2.0 yang andal?

Pertanyaan dan skenario

Pelanggan korporat menggunakan SaaS Anda sebagai penyedia layanan (service provider), dan penyedia identitasnya mengirimkan perubahan pengguna dan grup. Permintaan dapat terduplikasi, urutannya tertukar, tertunda, atau dicoba ulang setelah batas waktu habis (timeout). Layanan harus mendukung penyewa (tenant), pengidentifikasi eksternal, keanggotaan grup, penghapusan sementara (soft deletion), kemampuan audit, dan pencabutan cepat dengan tetap mempertahankan semantik sumber daya dan kesalahan SCIM 2.0.

Hal yang diuji oleh pewawancara

• Apakah kandidat memahami semantik User, Group, schemas, pemfilteran, dan PATCH pada SCIM?
• Bisakah mereka menghubungkan pemetaan sumber daya eksternal, kunci idempotensi, pembaruan konkuren, dan percobaan ulang ke dalam satu alur data?
• Apakah mereka membedakan antara active=false, permintaan penghapusan, dan pencabutan sesi aplikasi?
• Bisakah mereka menerapkan isolasi penyewa, cakupan token, audit, batas laju (rate limits), dan perlindungan bidang sensitif?

Pertanyaan klarifikasi untuk diajukan terlebih dahulu

Konfirmasikan apakah penyedia identitas adalah pemegang otoritas untuk profil, apakah grup didorong (pushed), apakah penghapusan permanen (hard deletion) diizinkan, target latensi sinkronisasi, dan skala penyewa. Perjelas apakah userName eksternal bersifat stabil, apakah perubahan nama email terjadi, batas ukuran grup, dukungan bulk, dan seberapa cepat sesi yang ada harus kedaluwarsa setelah penonaktifan. Jangan gunakan email sebagai kunci primer yang tidak dapat diubah.

Kerangka jawaban 30 detik

Simpan sumber daya eksternal SCIM dan akun lokal dalam pemetaan berskala penyewa, memisahkan pengidentifikasi eksternal yang stabil dari ID internal. Jadikan pembuatan, pembaruan, PATCH, penghapusan, dan kueri bersifat idempoten dengan sidik jari permintaan dan versi; tolak penulisan usang secara eksplisit. active=false memicu penonaktifan dan pencabutan sesi, sedangkan penghapusan mengikuti kebijakan retensi penyewa. Setiap permintaan memvalidasi penyewa, cakupan token, dan konteks audit, serta efek asinkron yang dapat dicoba ulang tidak boleh memberikan izin dua kali.

Pembahasan mendalam langkah demi langkah

1. Tentukan batasan sumber daya. Ekspos kemampuan SCIM yang benar-benar Anda dukung, seperti /Users, /Groups, /ResourceTypes, /Schemas, dan /ServiceProviderConfig. Jaga agar schemas konsisten dengan setiap jenis sumber daya dan kembalikan kesalahan yang dinormalisasi untuk filter yang tidak didukung.
2. Bangun pemetaan identitas. Per penyewa, simpan ID sumber daya eksternal, ID pengguna lokal, sistem sumber, dan versi saat ini. Bidang yang dapat berubah seperti userName dan email digunakan untuk pencarian atau tampilan, bukan untuk menggantikan pemetaan yang stabil; konflik memerlukan peninjauan alih-alih penggabungan diam-diam.
3. Terapkan idempotensi dan kontrol konkurensi. POST berulang mengembalikan sumber daya yang ada atau memutar ulang secara aman dari sidik jari permintaan. Terapkan operasi PATCH secara individual dan catat hasilnya. Jika didukung, wajibkan ETag atau kondisi versi agar penulisan yang usang tidak dapat menimpa data yang lebih baru.
4. Tangani siklus hidup pengguna dan grup. active=false mencabut izin aplikasi, memblokir login baru, dan mengakhiri sesi saat ini. Penghapusan permanen mengikuti aturan retensi dan audit. Perbarui keanggotaan grup berdasarkan selisih himpunan (set difference); kegagalan parsial tidak boleh menghapus setiap anggota yang belum dikonfirmasi.
5. Isolasi efek asinkron. Setelah API menulis ke tabel fakta lokal, masukkan sinkronisasi izin, notifikasi sambutan, dan peristiwa audit ke dalam antrean. Pesan memuat penyewa, versi sumber daya, dan kunci idempotensi; konsumen duplikat tidak dapat memberikan akses atau mengirim notifikasi dua kali.
6. Lindungi dan operasikan layanan. Token SCIM dibatasi untuk satu penyewa dan cakupan operasi, dengan rotasi, pencabutan, dan kedaluwarsa. Batasi paginasi, filter, dan ukuran bulk. Catat keberhasilan, penolakan, konflik, percobaan ulang, dan latensi penonaktifan tanpa mencatat token lengkap atau atribut sensitif ke dalam log.

Contoh jawaban berkualitas tinggi

Saya akan memperlakukan API SCIM sebagai batas sinkronisasi dari sumber identitas eksternal ke akun lokal. Setiap penyewa mendapatkan token, pemetaan sumber daya, dan jejak auditnya sendiri. Sumber daya User dan Group mempertahankan ID eksternal dan internal yang stabil serta mengikuti skema SCIM. Filter yang tidak didukung, operasi PATCH, atau aturan pengembalian menghasilkan kesalahan eksplisit alih-alih tebakan.

Penulisan pertama kali mendarat di tabel fakta lokal, kemudian mengantrekan efek izin yang dapat dicoba ulang berdasarkan versi sumber daya. ID eksternal, sidik jari permintaan, dan versi bersyarat membuat percobaan ulang bersifat idempoten; versi yang usang tidak dapat menimpa data baru. active=false mencabut izin, memblokir login baru, dan mengakhiri sesi, sementara penghapusan mengikuti retensi. Pembaruan grup menggunakan selisih himpunan dan mencoba ulang kegagalan parsial tanpa menghapus anggota yang belum dikonfirmasi. Pantau latensi sinkronisasi per penyewa, konflik, waktu dari penonaktifan hingga sesi kedaluwarsa, dan dead letters. Referensi mencakup RFC 7643, RFC 7644, dan panduan implementasi SCIM dari Okta.

Kesalahan umum

• Hanya mengimplementasikan POST /Users tanpa /ServiceProviderConfig, filter, PATCH, jenis kesalahan, dan paginasi.
• Menggunakan email sebagai satu-satunya kunci, sehingga menciptakan duplikat atau menautkan akun yang salah setelah perubahan nama.
• Memperlakukan percobaan ulang timeout sebagai perintah baru dan memberikan izin, mengirim notifikasi, atau menimpa bidang yang lebih baru dua kali.
• Menyembunyikan pengguna setelah active=false tanpa mencabut token, izin, dan sesi saat ini.
• Menghapus semua anggota grup lokal setelah kegagalan sinkronisasi parsial, mengubah masalah jaringan sementara menjadi kehilangan akses yang luas atau pemberian izin yang berlebihan.

Pertanyaan lanjutan dan tanggapan

Bagaimana jika penyedia identitas mengulangi permintaan pembuatan yang sama?

Cari penyewa dan ID sumber daya eksternal lalu pertahankan sidik jari permintaan atau versi. Kembalikan representasi stabil untuk sumber daya yang ada; jika muatan (payload) berkonflik, kembalikan kesalahan yang dapat didiagnosis dan lakukan audit alih-alih menimpa perubahan lokal secara diam-diam.

Bagaimana cara Anda menjaga kontinuitas akun setelah perubahan nama email?

Gunakan pemetaan ID sumber daya eksternal yang stabil ke ID akun lokal, dengan email sebagai atribut yang dapat diubah. Periksa keunikan tingkat penyewa, perbarui alias tampilan dan login, dan jangan pernah membuat akun baru atau mencocokkan lintas penyewa berdasarkan email.

Bagaimana Anda tetap aman ketika penonaktifan dan login tiba bersamaan?

Otorisasi membaca status akun yang dapat dilinearisasi (linearizable) atau versi pencabutan. Penonaktifan memajukan versi dan mencabut sesi; login memeriksanya kembali sebelum menerbitkan kredensial dan menolak akun yang dinonaktifkan, bahkan jika tugas izin asinkron yang lebih lama masih berjalan.