Migrasi ke SSO Terkelola

Fitur ini merupakan bagian dari paket Enterprise Plus.

Panduan ini ditujukan untuk admin organisasi yang mengonversi organisasi yang sudah ada dari organisasi standar menjadi organisasi Managed SSO.

Hal terpenting yang perlu dipahami sebelum Anda memulai: akun Hugging Face pribadi yang sudah ada milik anggota tidak dikonversi menjadi akun yang dikelola. Setiap anggota akan mendapatkan akun baru yang dikelola, yang disiapkan oleh Identity Provider (IdP) Anda. Sebelum seorang anggota dapat disiapkan, mereka harus membebaskan alamat email kerja mereka di akun pribadi mereka.

Sepanjang panduan ini, kami menggunakan my-org sebagai contoh nama organisasi.

Prasyarat

SSO harus sudah dikonfigurasi, diuji, dan diaktifkan di organisasi Anda. Migrasi ini menggunakan ulang aplikasi OIDC atau SAML yang sudah ada.

Langkah-langkah migrasi

1. Siapkan anggota Anda. Telusuri daftar periksa pra-migrasi bersama anggota Anda.
2. Hubungi Hugging Face. Sampaikan kepada tim Hugging Face dan konfirmasi perpindahan. Kami akan mengonversi organisasi dan mengirimkan kredensial untuk akun break-glass my-org:owner.
3. Minta anggota untuk membebaskan alamat email kerja mereka. Lihat Membebaskan alamat email kerja. Lakukan ini sebelum mengaktifkan provisioning: pengguna yang sudah ditugaskan ke aplikasi SSO Anda akan diproses begitu SCIM diaktifkan. Tim Hugging Face dapat mengirimkan daftar anggota yang akun pribadi mereka masih menggunakan alamat email kerja, sehingga Anda dapat menindaklanjuti mereka.
4. Set up SCIM in your IdP. Gunakan SCIM Tenant URL dan token dari organisasi Anda di SSO → SCIM pengaturan, di aplikasi OIDC atau SAML yang sudah ada, lalu ikuti panduan untuk IdP Anda.
   • Okta: ikuti panduan Okta, termasuk Langkah 3. Name ID harus berupa ID pengguna Okta.
   • Microsoft Entra ID: ikuti panduan Entra ID. Nilai userName harus mengikuti aturan nama pengguna, sehingga nilai bergaya email seperti jdoe@example.com akan ditolak.
   • IdP lainnya: lihat User Provisioning (SCIM), dengan aturan nama pengguna yang sama.
5. Tetapkan pengguna dan grup di IdP Anda. Akun dikelola dibuat saat pengguna diproses.
6. Hapus akun pribadi yang tersisa dari organisasi segera setelah akun terkelola masing-masing anggota diproses. Langkah ini diperlukan untuk keamanan, karena akun pribadi tetap memiliki akses hingga dihapus. Penghapusan ini juga akan menghapus mereka dari Resource Groups organisasi.
7. (Opsional) Pemetaan grup ke Resource Groups dan peran. Hubungkan grup SCIM Anda ke Resource Groups, dan atur Role Mapping untuk menetapkan peran organisasi dari IdP Anda. Resource Group hanya dapat dihubungkan ke grup SCIM jika tidak memiliki anggota dan auto-join dimatikan. Jika auto-join diaktifkan, akun managed yang baru diproses juga akan ditambahkan ke grup tersebut, sehingga matikan auto-join sebelum memproses pengguna, atau hapus anggota yang tersisa sebelum menghubungkan.

Apa yang berubah

Apa yang dilakukan konversi

• Konversi dilakukan oleh tim Hugging Face. Tidak ada opsi self-serve. Setelah Anda memintanya, tim Hugging Face akan mengalihkan organisasi Anda ke managed mode.
• Konten dan konfigurasi organisasi Anda tetap seperti semula. Repositori, pengaturan, Resource Groups, dan konfigurasi SSO Anda yang ada (aplikasi OIDC atau SAML) dipertahankan. Anda tetap menggunakan aplikasi IdP yang sama, meskipun beberapa pengaturan mungkin perlu disesuaikan untuk SCIM (lihat langkah 4).
• Akun admin break-glass dibuat, bernama my-org:owner. Akun ini masuk menggunakan nama pengguna dan kata sandi (bukan melalui SSO) dan merupakan admin organisasi. Tim Hugging Face membagikan kredensialnya kepada Anda. Simpan dengan aman: akun ini memungkinkan Anda mengakses organisasi Anda jika IdP Anda tidak tersedia atau salah dikonfigurasi.
• SSO tidak lagi dapat dibuat opsional. Namun, SSO masih dapat dinonaktifkan sepenuhnya.

Menonaktifkan SSO pada organisasi yang dikelola akan mengunci akses semua pengguna yang dikelola, karena akun yang dikelola tidak memiliki kata sandi.

Akun yang dikelola adalah akun baru

• Akun Hugging Face pribadi yang sudah ada tidak dikonversi, digabungkan, atau ditautkan ke akun yang dikelola. Setiap anggota mendapatkan akun baru, yang dibuat oleh IdP Anda melalui SCIM ketika pengguna ditugaskan di IdP.
• Nama pengguna yang dikelola diberi awalan nama organisasi: <org-name>:<username>, misalnya my-org:jdoe.
• Pengguna yang dikelola hanya masuk melalui IdP Anda. Mereka tidak memiliki kata sandi Hugging Face, dan “Forgot password” tidak berfungsi untuk mereka.
• Akun yang dikelola tunduk pada batasan untuk akun yang dikelola.

Keanggotaan

• Anggota reguler tidak lagi dapat ditambahkan melalui undangan. Anggota internal harus diproses melalui SCIM.
• Undangan tetap tersedia hanya untuk kolaborator eksternal.

Akun pribadi yang sudah ada di organisasi

Akun pribadi yang masih menjadi anggota organisasi setelah konversi tetap mempertahankan perannya. Token akses, aplikasi OAuth yang sudah mereka otorisasi, dan git via SSH tetap berfungsi, karena hal-hal ini tidak diperiksa terhadap SSO. Mereka tidak dapat memulai login SSO baru ke organisasi lagi:

• Jika pengguna masuk dengan akun pribadi mereka, atau akun tersebut sudah terhubung ke IdP Anda, mereka akan melihat: You cannot login with SSO with this account because it's not managed by this organization. Contact your organization administrators.
• Jika tidak, mereka akan melihat User not found.

Sebelum Anda bermigrasi

Lakukan pemeriksaan daftar ini bersama anggota Anda sebelum meminta konversi:

• Repositori pribadi: anggota yang memiliki repositori di namespace pribadi mereka dan ingin tetap mengaksesnya dengan akun terkelola baru sebaiknya mentransfernya ke organisasi sebelum perpindahan. Akun terkelola tidak dapat memiliki konten di namespace pribadi. Anggota masih dapat mengakses repositori apa pun di bawah namespace pribadi mereka melalui akun pribadi (non-terkelola) mereka.
• Token dan otomasi: token dari akun pribadi tetap mempertahankan aksesnya ke organisasi hingga akun tersebut dihapus dari organisasi. Migrasikan skrip, pekerjaan CI, dan pipeline ke akun layanan, atau ke token yang dibuat dari akun terkelola setelah perpindahan, lalu hapus akun lama.
• Organisasi lain: akun yang dikelola tidak dapat bergabung ke organisasi lain. Anggota yang perlu terus bekerja di organisasi lain sebaiknya mempertahankan akun pribadi terpisah (lihat opsi 2 di bawah).
• Alamat email kerja: setiap anggota harus membebaskan alamat email kerja mereka sebelum mereka diproses. Lihat Membebaskan alamat email kerja.

Membebaskan alamat email kerja

Alamat email hanya dapat dimiliki oleh satu akun Hugging Face. Hal ini berlaku untuk semua alamat email pada sebuah akun, baik utama maupun sekunder. Pencocokan tidak membedakan huruf besar dan kecil.

Ketika SCIM mencoba membuat akun terkelola dengan email kerja yang sudah digunakan oleh akun pribadi, provisioning gagal dengan error 409:

The email address (jdoe@example.com) is already associated with another Hugging Face account. Please delete the account.

IdP Anda menampilkan ini sebagai kesalahan provisioning untuk pengguna tersebut.

Untuk menghindari hal ini, setiap anggota harus membebaskan alamat email kerja mereka sebelum mereka diproses, menggunakan salah satu dari dua opsi di bawah ini.

Opsi mana yang harus saya pilih?

• Jika Anda hanya menggunakan akun Hugging Face Anda untuk pekerjaan di organisasi ini, pilih opsi 1: hapus akun pribadi.
• Jika Anda juga menggunakannya untuk pekerjaan open-source, proyek pribadi, atau organisasi lain, pilih opsi 2: pertahankan akun pribadi dan hapus email kerja dari akun tersebut.

Opsi 1: Hapus akun pribadi

Hapus akun pribadi Anda dari pengaturan akun. Tindakan ini secara permanen menghapus semua repositori di namespace pribadi Anda dan mengeluarkan Anda dari setiap organisasi.

Menghapus akun bersifat permanen. Pindahkan semua repositori yang ingin Anda simpan ke organisasi terlebih dahulu.

Penghapusan diblokir jika Anda adalah satu-satunya admin dari organisasi lain. Tambahkan admin lain ke organisasi tersebut, atau hapus organisasi itu terlebih dahulu. Organisasi yang sedang dimigrasikan tidak menjadi masalah, karena my-org:owner juga merupakan admin.

Opsi 2: Pertahankan akun pribadi

1. Di pengaturan akun Anda, tambahkan alamat email pribadi dan verifikasi.
2. Jadikan alamat email pribadi sebagai email utama Anda.
3. Hapus alamat email kerja sepenuhnya. Membuatnya sebagai email sekunder tidak cukup.

Jaga akun pribadi Anda tetap berada di organisasi hingga akun yang dikelola Anda diproses. Admin Anda akan menghapusnya kemudian.

Jika organisasi Anda sudah mengaktifkan Managed SSO dan memiliki domain email terverifikasi, masuk dengan alamat email pada domain tersebut akan mengalihkan Anda ke halaman SSO organisasi. Untuk masuk ke akun pribadi Anda, gunakan nama pengguna Anda.

Setelah email kerja tersedia, admin dapat mencoba lagi provisioning untuk pengguna tersebut di IdP, atau menunggu sinkronisasi berikutnya untuk mengambilnya.

Setelah migrasi

Siklus hidup pengguna dikelola dari IdP Anda:

• Menonaktifkan pengguna di IdP Anda akan menghapus mereka dari organisasi. Jika pengguna yang sama diaktifkan kembali nanti, akun terkelola yang sudah ada akan digunakan kembali.
• Menghapus pengguna melalui SCIM akan menghapus akun yang dikelola secara permanen. Lihat Deprovisioning.