Bagaimanakah anda akan mereka bentuk perkhidmatan peruntukan SCIM 2.0 yang boleh dipercayai?

Soalan dan senario

Pelanggan perusahaan menggunakan SaaS anda sebagai penyedia perkhidmatan (service provider), dan penyedia identitinya menghantar perubahan pengguna dan kumpulan. Permintaan boleh diduplikasi, disusun semula, ditangguhkan atau dicuba semula selepas tamat masa. Perkhidmatan ini mesti menyokong penyewa (tenants), pengecam luaran, keahlian kumpulan, pemadaman lembut (soft deletion), kebolehauRegionan dan pembatalan segera sambil mengekalkan semantik sumber dan ralat SCIM 2.0.

Perkara yang diuji oleh penemu duga

• Adakah calon memahami semantik User, Group, schemas, penapisan dan PATCH SCIM?
• Bolehkah mereka menghubungkan pemetaan sumber luaran, kunci keidempotenan, kemas kini serentak dan percubaan semula ke dalam satu aliran data?
• Adakah mereka membezakan active=false, permintaan pemadaman dan pembatalan sesi aplikasi?
• Bolehkah mereka menguatkuasakan pengasingan penyewa, skop token, pengauditan, had kadar (rate limits) dan perlindungan medan sensitif?

Soalan penjelasan untuk ditanya terlebih dahulu

Sahkan sama ada penyedia identiti adalah berwibawa (authoritative) untuk profil, sama ada kumpulan ditolak (pushed), sama ada pemadaman kekal (hard deletion) dibenarkan, sasaran kependaman penyegerakan dan skala penyewa. Jelaskan sama ada userName luaran adalah stabil, sama ada penamaan semula e-mel berlaku, had saiz kumpulan, sokongan pukal (bulk) dan berapa cepat sesi sedia ada mesti tamat tempoh selepas penyahaktifan. Jangan gunakan e-mel sebagai kunci utama yang tidak boleh diubah.

Rangka kerja jawapan 30 saat

Simpan sumber luaran SCIM dan akaun tempatan dalam pemetaan berskop penyewa, memastikan pengecam luaran yang stabil diasingkan daripada ID dalaman. Jadikan cipta, kemas kini, PATCH, padam dan pertanyaan bersifat idempoten dengan cap jari permintaan dan versi; tolak penulisan basi secara eksplisit. active=false mencetuskan penyahaktifan dan pembatalan sesi, manakala pemadaman mengikut dasar pengekalan penyewa. Setiap permintaan mengesahkan penyewa, skop token dan konteks audit, dan kesan tak segerak (asynchronous) yang boleh dicuba semula tidak boleh memberikan kebenaran dua kali.

Pecahan terperinci langkah demi langkah

1. Tentukan sempadan sumber. Dedahkan keupayaan SCIM yang anda benar-benar sokong, seperti /Users, /Groups, /ResourceTypes, /Schemas dan /ServiceProviderConfig. Pastikan schemas konsisten dengan setiap jenis sumber dan kembalikan ralat ternormal untuk penapis yang tidak disokong.
2. Bina pemetaan identiti. Bagi setiap penyewa, simpan ID sumber luaran, ID pengguna tempatan, sistem sumber dan versi semasa. Medan boleh ubah seperti userName dan e-mel adalah untuk carian atau paparan, bukan untuk menggantikan pemetaan yang stabil; konflik memerlukan semakan dan bukannya penggabungan senyap.
3. Laksanakan keidempotenan dan kawalan keserentakan. POST yang berulang mengembalikan sumber sedia ada atau memainkan semula dengan selamat daripada cap jari permintaan. Gunakan operasi PATCH secara individu dan rekodkan hasilnya. Jika disokong, perlukan syarat ETag atau versi supaya penulisan basi tidak dapat menimpa data yang lebih baharu.
4. Kendalikan kitaran hayat pengguna dan kumpulan. active=false membatalkan kebenaran aplikasi, menyekat log masuk baharu dan menamatkan sesi semasa. Pemadaman kekal mengikut peraturan pengekalan dan audit. Kemas kini keahlian kumpulan mengikut perbezaan set (set difference); kegagalan separa tidak boleh mengalih keluar setiap ahli yang tidak disahkan.
5. Asingkan kesan tak segerak. Selepas API menulis jadual fakta tempatan, masukkan penyegerakan kebenaran, pemberitahuan alu-aluan dan peristiwa audit ke dalam baris gilir. Mesej membawa penyewa, versi sumber dan kunci keidempotenan; pengguna (consumer) pendua tidak boleh memberikan akses atau menghantar pemberitahuan dua kali.
6. Lindungi dan kendalikan perkhidmatan. Token SCIM dihadkan kepada satu penyewa dan skop operasi, dengan penggiliran, pembatalan dan tamat tempoh. Hadkan penomboran halaman (pagination), penapis dan saiz pukal. Rekod kejayaan, penolakan, konflik, percubaan semula dan kependaman penyahaktifan tanpa merekodkan token lengkap atau atribut sensitif.

Contoh jawapan berkualiti tinggi

Saya akan menganggap API SCIM sebagai sempadan penyegerakan daripada sumber identiti luaran kepada akaun tempatan. Setiap penyewa mendapat token, pemetaan sumber dan jejak auditnya sendiri. Sumber User dan Group mengekalkan ID luaran dan dalaman yang stabil serta mengikut skema SCIM. Penapis yang tidak disokong, operasi PATCH atau peraturan kebolehkembalian menghasilkan ralat eksplisit dan bukannya tekaan.

Penulisan mendarat di jadual fakta tempatan terlebih dahulu, kemudian memasukkan kesan kebenaran yang boleh dicuba semula ke dalam baris gilir mengikut versi sumber. ID luaran, cap jari permintaan dan versi bersyarat menjadikan percubaan semula idempoten; versi basi tidak boleh menimpa data baharu. active=false membatalkan kebenaran, menyekat log masuk baharu dan menamatkan sesi, manakala pemadaman mengikut pengekalan. Kemas kini kumpulan menggunakan perbezaan set dan mencuba semula kegagalan separa tanpa mengosongkan ahli yang belum disahkan. Pantau kependaman penyegerakan bagi setiap penyewa, konflik, masa penyahaktifan-ke-tamat-tempoh-sesi dan dead letters. Rujukan termasuk RFC 7643, RFC 7644 dan panduan pelaksanaan SCIM Okta.

Kesilapan biasa

• Melaksanakan hanya POST /Users tanpa /ServiceProviderConfig, penapis, PATCH, jenis ralat dan penomboran halaman.
• Menggunakan e-mel sebagai kunci tunggal, mewujudkan pendua atau memautkan akaun yang salah selepas penamaan semula.
• Menganggap percubaan semula tamat masa sebagai arahan baharu dan memberikan kebenaran, menghantar pemberitahuan atau menimpa medan yang lebih baharu dua kali.
• Menyembunyikan pengguna selepas active=false tanpa membatalkan token, kebenaran dan sesi semasa.
• Mengosongkan semua ahli kumpulan tempatan selepas kegagalan penyegerakan separa, mengubah isu rangkaian sementara kepada kehilangan akses yang meluas atau pemberian kebenaran berlebihan.

Soalan susulan dan jawapan

Bagaimana jika penyedia identiti mengulangi permintaan cipta yang sama?

Cari penyewa dan ID sumber luaran serta simpan cap jari permintaan atau versi. Kembalikan perwakilan yang stabil untuk sumber sedia ada; jika muatan berkonflik, kembalikan ralat yang boleh didiagnosis dan auditkannya dan bukannya menimpa perubahan tempatan secara senyap.

Bagaimanakah anda mengekalkan kesinambungan akaun selepas penamaan semula e-mel?

Gunakan pemetaan ID sumber luaran yang stabil kepada ID akaun tempatan, dengan e-mel sebagai atribut boleh ubah. Semak keunikan peringkat penyewa, kemas kini alias paparan dan log masuk, dan jangan sekali-kali mencipta akaun baharu atau memadankan merentas penyewa mengikut e-mel.

Bagaimanakah anda kekal selamat apabila penyahaktifan dan log masuk tiba serentak?

Kebenaran membaca keadaan akaun yang boleh dilinearkan (linearizable) atau versi pembatalan. Penyahaktifan memajukan versi dan membatalkan sesi; log masuk menyemaknya semula sebelum mengeluarkan kelayakan dan menolak akaun yang dinyahaktifkan, walaupun tugas kebenaran tak segerak yang lebih lama masih berjalan.