Identiti Bersekutu: SAML, OAuth dan OpenID Connect

Dalam perusahaan moden, pekerja perlu mengaccess berdozen-dozen aplikasi — aplikasi awan, alat SaaS, portal rakan kongsi dan sistem dalaman — yang setiap satunya mungkin diselenggara oleh organisasi yang berbeza. Mencipta dan mengurus akaun berasingan untuk setiap aplikasi adalah tidak selamat (penggandaan kelayakan) dan tidak cekap. Identiti bersekutu menyelesaikan masalah ini dengan membolehkan Penyedia Identiti (IdP) — sumber identiti yang dipercayai dan berautoriti — mengesahkan pengguna serta berkongsi identiti yang telah disahkan itu dengan Penyedia Perkhidmatan (SP) merentas sempadan organisasi. Pengguna mengesahkan diri sekali dan mendapat access kepada berbilang sistem tanpa memasukkan semula kelayakan.

Single Sign-On (SSO) membolehkan pengguna mengesahkan diri sekali dan mengaccess berbilang aplikasi dalam sesuatu sesi tanpa pengesahan semula. Pengguna log masuk ke Penyedia Identiti (Active Directory korporat, Okta, Azure AD), menerima token sesi atau penegasan, lalu mengemukakan token ini kepada setiap Penyedia Perkhidmatan yang dilawati. SSO meningkatkan keselamatan dengan mengurangkan bilangan kata laluan yang perlu diurus oleh pengguna (sekali gus mengurangkan penggunaan semula), membolehkan penguatkuasaan dasar pengesahan secara berpusat, dan membenarkan pembatalan access serta-merta merentas semua aplikasi bersepadu apabila akaun dinyahaktifkan pada peringkat IdP.

SAML (Bahasa Penandaan Penegasan Keselamatan) 2.0 ialah standard terbuka berasaskan XML untuk menukar data pengesahan dan authorization antara Penyedia Identiti dan Penyedia Perkhidmatan. Aliran SAML: (1) pengguna mengaccess Penyedia Perkhidmatan (contohnya, Salesforce), (2) SP mengubah hala pengguna ke Penyedia Identiti (contohnya, Okta), (3) pengguna mengesahkan diri di IdP, (4) IdP mengeluarkan Penegasan SAML XML yang ditandatangani dan mengandungi identiti serta atribut pengguna, (5) penegasan dikembalikan kepada SP, (6) SP mengesahkan tandatangan penegasan menggunakan kunci awam IdP dan memberikan access. SAML digunakan secara meluas untuk SSO perusahaan dalam aplikasi web.

Tiga pihak mengambil bahagian dalam persekutuan SAML. Principal ialah pengguna (atau sistem) yang ingin mendapatkan access — pihak ini memulakan proses pengesahan. Penyedia Identiti (IdP) ialah sumber identiti berautoriti yang mengesahkan principal dan mengeluarkan penegasan — contohnya Microsoft Azure AD, Okta, Ping Identity dan ADFS. Penyedia Perkhidmatan (SP) menggunakan penegasan dan memberikan access berdasarkan penegasan tersebut — contohnya Salesforce, Google Workspace, AWS dan mana-mana aplikasi yang didayakan SAML. SP dan IdP mewujudkan kepercayaan terlebih dahulu dengan bertukar metadata yang mengandungi URL titik akhir serta sijil tandatangan masing-masing.

OAuth 2.0 ialah rangka kerja authorization (bukan protokol pengesahan) yang membolehkan aplikasi pihak ketiga mengaccess sumber bagi pihak pengguna tanpa mendedahkan kelayakan pengguna. Kes penggunaan klasiknya ialah: 'Benarkan aplikasi penyuntingan foto ini mengaccess Google Photos anda.' OAuth 2.0 memperkenalkan empat peranan: Pemilik Sumber (pengguna), Client (aplikasi pihak ketiga), Pelayan Authorization (mengeluarkan token) dan Pelayan Sumber (menempatkan sumber yang dilindungi). Pengguna memberikan authorization kepada client, yang menerima token access untuk dikemukakan kepada pelayan sumber — tanpa memerlukan kata laluan sebenar pengguna.

Aliran Kod Authorization ialah aliran OAuth 2.0 yang paling selamat untuk aplikasi web. Alirannya: (1) Client mengubah hala pengguna ke Pelayan Authorization bersama skop yang diminta; (2) User mengesahkan diri dan memberikan persetujuan pada Pelayan Authorization; (3) Pelayan Authorization mengubah hala kembali dengan kod authorization yang berjangka hayat pendek; (4) Client menukar kod tersebut dengan token access (dan secara pilihan token penyegaran) melalui panggilan pelayan-ke-pelayan menggunakan kelayakan client; (5) Client menggunakan token access untuk memanggil Pelayan Sumber. Pertukaran kod berlaku pada bahagian pelayan, sekali gus menghalang token access daripada terdedah dalam sejarah pelayar atau log.

OpenID Connect (OIDC) ialah lapisan pengesahan yang dibina di atas OAuth 2.0. OAuth hanya menyediakan authorization (token access membuktikan perkara yang boleh dilakukan oleh client); OIDC menambahkan pengesahan ( token ID yang membuktikan identiti pengguna). OIDC menambahkan skop openid pada aliran OAuth dan mengembalikan Token ID JWT (JSON Web Token) yang ditandatangani bersama token access. Token ID mengandungi tuntutan (nama, e-mel, sub [pengenal subjek]) yang mengenal pasti pengguna. OIDC kini merupakan protokol utama untuk SSO yang menghadap pengguna — butang 'Log masuk dengan Google/Apple/Microsoft' semuanya menggunakan OIDC.

JSON Web Tokens (JWT) ialah format padat dan selamat URL untuk mewakili tuntutan antara pihak. JWT mempunyai tiga bahagian yang dikodkan dalam base64url dan dipisahkan oleh noktah: Header (algoritma dan jenis token), Payload (tuntutan: iss, sub, aud, exp, iat dan tuntutan tersuai), serta Signature (tandatangan kriptografi yang mengesahkan integriti token). JWT adalah serba lengkap — Pelayan Sumber boleh mengesahkannya tanpa memanggil semula Pelayan Authorization, sekali gus meningkatkan prestasi dan membolehkan seni bina tanpa keadaan. Keperluan keselamatan kritikal: sentiasa sahkan tandatangan JWT serta semak tuntutan exp (tamat tempoh) dan aud (audiens).

Memahami bila setiap standard digunakan amat penting untuk peperiksaan Security+. SAML 2.0: SSO perusahaan untuk aplikasi web, aliran berasaskan pelayar dan penegasan XML. Teknologi legasi tetapi digunakan secara meluas dalam perusahaan. OAuth 2.0: authorization API — memberikan aplikasi pihak ketiga access terhad kepada sumber. Ia tidak mengesahkan pengguna secara langsung. OIDC: pengesahan pengguna umum dan perusahaan moden (SSO), dibina di atas OAuth 2.0. Ia mengembalikan token ID JWT yang mengenal pasti pengguna. Dalam amalan, persekitaran perusahaan sering menggunakan SAML untuk SSO aplikasi dan OIDC untuk pengesahan API/mudah alih. Persekitaran cloud-native moden lebih mengutamakan OIDC berbanding SAML kerana format JSON/JWT dan sokongan mudah alihnya yang lebih baik.

Sistem identiti bersekutu memperkenalkan vektor serangan tertentu. Serangan pengulangan penegasan: penyerang memintas penegasan SAML dan mengulang penghantarannya untuk mendapatkan access. Langkah mitigasinya ialah jangka hayat penegasan yang pendek dan ID penegasan yang hanya boleh digunakan sekali. Pembungkusan tandatangan XML (XSW): dalam SAML, penyerang kadangkala boleh memanipulasi XML yang ditandatangani untuk mengubah tuntutan sambil mengekalkan tandatangan yang sah pada kandungan asal. Kekeliruan algoritma JWT: jika pelayan menerima kedua-dua algoritma RS256 (asimetrik) dan HS256 (simetrik), penyerang boleh memalsukan JWT dengan menggunakan kunci awam pelayan sebagai rahsia HMAC untuk HS256. Sentiasa sahkan bahawa Header algoritma sepadan dengan algoritma yang dijangka. Pengubah hala terbuka: URI penghalaan semula OAuth mesti dipadankan tepat-tepat untuk menghalang kecurian token melalui penghalaan semula ke tapak yang dikawal penyerang.

Persekutuan identiti perusahaan sering memerlukan penyegerakan data identiti pengguna antara sistem. SCIM (Pengurusan Identiti Rentas Domain Sistem) ialah standard API REST untuk mengautomatikkan pembekalan dan nyahbekalan pengguna antara Penyedia Identiti dan Penyedia Perkhidmatan yang disambungkan. Apabila pekerja baharu ditambahkan pada Azure AD (IdP), SCIM mencipta akaun mereka secara automatik dalam Salesforce, Slack, GitHub dan aplikasi lain yang serasi dengan SCIM. Apabila pekerja tersebut diberhentikan, SCIM menyahaktifkan semua akaun serentak — menutup tempoh apabila akaun yatim boleh dieksploitasi. SCIM melengkapi protokol SSO (SAML/OIDC) dengan mengendalikan pengurusan kitar hayat yang tidak ditangani oleh protokol SSO.

Dalam pelajaran ini, anda telah mempelajari bahawa: SAML 2.0 menggunakan penegasan XML untuk SSO perusahaan berasaskan pelayar; OAuth 2.0 ialah rangka kerja authorization untuk pendelegasian access API; OpenID Connect menambahkan pengesahan (token ID JWT) pada OAuth; dan SCIM mengautomatikkan pengurusan kitar hayat identiti merentas sistem bersekutu. Kursus Pengesahan dan Authorization ini telah selesai — seterusnya, kita akan meneroka Asas Keselamatan Network.