Sign inGet Started

SSO dan provisioning

Single sign-on (SSO) memungkinkan anggota masuk ke Bird melalui identity provider Anda tanpa perlu kata sandi Bird terpisah. Bird mendukung koneksi SAML 2.0 dan OpenID Connect (OIDC).

Penyiapan SSO adalah tugas Owner organisasi, dan kontrolnya ada di halaman Single sign-on organisasi Anda. Anggota yang diberi izin SSO dapat mengelola koneksi tanpa menjadi Owner.

Sign-in Google atau GitHub personal terpisah dari SSO organisasi. Lihat Login, password & MFA.

Cara kerja SSO

Koneksi SSO mencakup satu atau beberapa domain email terverifikasi, seperti yourcompany.com. Anggota pada domain tersebut melakukan autentikasi melalui identity provider Anda. Izin Bird mereka tetap berasal dari peran organisasi dan workspace mereka.

Apa saja yang perlu disiapkan

Owner organisasi dan administrator identity provider menyelesaikan penyiapan:

  1. Buktikan kepemilikan domain. Bird memberikan DNS record untuk Anda publikasikan pada setiap domain email yang dicakup koneksi. Pemberlakuan tidak bisa diaktifkan sampai domain terverifikasi.
  2. Konfigurasikan koneksi. Untuk SAML, berikan metadata identity provider, atau URL sign-in dan sertifikat penandatanganan. Untuk OIDC, berikan issuer dan kredensial klien. Salin detail service-provider atau redirect dari Bird ke identity provider Anda.
  3. Uji koneksi. Selesaikan sign-in percobaan sebelum Anda mengaktifkan koneksi. Apa pun protokol yang dipilih, draft yang lolos pengujian akan diaktifkan untuk Anda, selama organisasi Anda memiliki domain terverifikasi dan belum melampaui batas koneksi aktif.
  4. Pilih apakah SSO diwajibkan. Saat SSO opsional, anggota dapat menggunakan SSO atau metode sign-in lain yang tersedia. Saat diwajibkan, anggota harus menyelesaikan SSO untuk mengakses organisasi. Mewajibkan SSO memerlukan koneksi aktif dan setidaknya satu domain terverifikasi.

Mewajibkan SSO berlaku segera pada setiap permintaan, bukan hanya pada sign-in berikutnya. Anggota yang sesi aktifnya tidak dibuat melalui identity provider Anda kehilangan akses ke organisasi sampai mereka masuk kembali melalui identity provider tersebut, jadi rencanakan perubahan ini sesuai jadwal kerja tim Anda, bukan mengumumkannya setelah diterapkan. Owner organisasi adalah pengecualian: Owner tetap bisa mengakses dengan kata sandi Bird mereka, dan inilah yang mencegah koneksi yang salah dikonfigurasi mengunci semua orang.

Siapkan identity provider Anda

Langkah 2 adalah bagian yang berbeda di setiap provider: nilai yang sama memiliki nama berbeda di masing-masing provider, dan masing-masing memiliki pengaturan yang menolak setiap sign-in jika salah dikonfigurasi. Nama field milik Bird adalah yang ada di halaman koneksi, di bawah Register these with your identity provider.

Untuk provider SAML 2.0 atau OpenID Connect lainnya, empat langkah di atas adalah keseluruhan yang diperlukan.

Menyiapkan SAML tanpa nilai placeholder

Entity ID dan Assertion Consumer Service URL koneksi SAML diturunkan dari koneksi itu sendiri, sehingga belum ada sampai Anda membuatnya. Ini menciptakan ketergantungan melingkar: identity provider Anda memerlukan nilai-nilai tersebut, dan nilai-nilai itu memerlukan koneksi.

Buat koneksi terlebih dahulu. Di Add connection, pilih SAML lalu I have not set up my provider yet. Koneksi dibuat sebagai draft tanpa detail identity provider, dan membukanya menampilkan nilai-nilai yang perlu didaftarkan di bawah Register these with your identity provider. Konfigurasikan provider Anda dengan nilai-nilai tersebut, lalu kembali dan gunakan Supply the details pada koneksi yang sama, dalam format apa pun yang Anda miliki:

  • metadata URL, yang kami ambil dan baca
  • metadata document itu sendiri, untuk provider yang memberikan file alih-alih menghostingnya
  • entity ID, sign-in URL, dan signing certificates, dimasukkan langsung

Dokumen yang diunggah dibaca untuk ketiga nilai tersebut dan tidak disimpan.

Sampai detail tersebut diberikan, koneksi tetap berstatus draft: tidak melayani sign-in dan tidak bisa diaktifkan.

Cara anggota diidentifikasi

Koneksi SAML mengidentifikasi setiap anggota berdasarkan NameID yang dikirim provider Anda, dan identifier tersebut bersifat permanen bagi siapa pun yang masuk. Penyiapan koneksi tidak meminta Anda memilih format. Jika Anda memberikan metadata URL atau dokumen, kami membaca apa yang diiklankan provider Anda di sana dan mengunci koneksi pada format tersebut. Jika Anda memasukkan detail secara manual, tidak ada metadata untuk dibaca, sehingga koneksi dikunci pada permanent ID.

Yang bisa Anda kontrol adalah nilai di baliknya. Atur application username di provider Anda ke sesuatu yang buram dan tidak pernah dialihkan, lalu kirim alamat email secara terpisah sebagai atribut email. Alamat email sebagai identifier lemah selamanya: jika alamat tersebut pernah dialihkan, orang berikutnya yang menerimanya mewarisi akun Bird.

Metadata menyatakan apa yang bisa dikirim provider Anda; konfigurasi aplikasinya menentukan apa yang benar-benar dikirim, dan keduanya bisa berbeda. Oleh karena itu, sign-in percobaan di langkah 3 melaporkan identifier dan format yang sebenarnya dibawa assertion, dan laporan itulah cara Anda memeriksa kecocokan keduanya sebelum siapa pun mengandalkan koneksi. Kami juga menolak identifier berlabel persistent yang sebenarnya adalah alamat email.

Jika pengujian melaporkan format yang tidak Anda harapkan, ada dua cara untuk memperbaikinya, dan mana yang tepat bergantung pada apa yang salah:

  • Provider mengirim hal yang salah. Ubah application username di provider Anda, lalu uji kembali. Ini biasanya perbaikan yang tepat, karena identifier buram adalah yang layak dipertahankan.
  • Koneksi dikunci pada hal yang salah. Buka Edit pada koneksi dan ubah format NameID ke format yang dikirim provider Anda.

Lakukan salah satu sebelum anggota mulai masuk. Setelah mereka masuk, akun mereka ditautkan ke identifier yang berlaku, sehingga format terkunci dan perubahan ditolak. Buat koneksi baru untuk format yang baru.

Mengganti provider

Detail identity provider pada koneksi SAML bisa diganti selama belum ada yang masuk melaluinya. Setelah anggota menggunakannya, akun mereka ditautkan ke identifier yang dikirim provider saat ini, sehingga penggantian ditolak. Buat koneksi baru untuk provider baru. Pada koneksi OIDC, Anda bisa merotasi client secret kapan saja tanpa mengubah identifier anggota, tetapi provider itu sendiri tidak bisa diganti.

Sign-in percobaan di langkah 3 tidak dihitung. Pengujian tidak menautkan akun dan tidak memberikan akses, sehingga koneksi yang sudah disiapkan dan diuji tetapi belum diberikan ke tim Anda masih bisa diarahkan ulang.

Apa yang berubah bagi tim Anda

Koneksi dapat memberikan akses default organisasi dan workspace kepada anggota pada sign-in SSO pertama yang berhasil. Konfigurasikan akses default tersebut secara eksplisit; jika tidak, undang anggota dan tetapkan peran sebelum mereka masuk. Lihat Users, teams & roles.

Menangguhkan koneksi mencegah sign-in baru melaluinya. Tinjau keanggotaan Bird dan sesi aktif secara terpisah saat seseorang meninggalkan perusahaan Anda.

Langkah berikutnya

Lanjutkan dengan dokumentasi, panduan, dan contoh untuk topik ini.