SAML metama'lumotlari - SAML metadata - Wikipedia

[CS 1]The SAML metama'lumotlari standarti XML asosidagi standartlar oilasiga tegishli bo'lib, ular nomi bilan tanilgan Xavfsizlik tasdiqini belgilash tili (SAML) tomonidan nashr etilgan OASIS 2005 yilda. SAML metadata hujjati a kabi SAML tarqatilishini tavsiflaydi SAML identifikatori provayderi yoki a SAML xizmat ko'rsatuvchi provayderi. Amaliyotlar metamalumotlarni almashib, ishonch va o'zaro hamkorlikning asosini belgilaydi.

SAML metama'lumotlariga kirish

Xavfsiz o'zaro hamkorlik qilish uchun sheriklar metadatani har qanday shaklda va iloji boricha almashadilar. Har holda, hech bo'lmaganda quyidagi metadata almashinilishi kerak:

  • Korxona identifikatori
  • Kriptografik kalitlar
  • Protokolning so'nggi nuqtalari (bog'lash joylari va joylari)

Har bir SAML tizim sub'ekti shaxs identifikatoriga, dasturiy ta'minot konfiguratsiyalarida, ishonchli shaxslar uchun ma'lumotlar bazalarida va mijoz tomonidan ishlatiladigan cookie-fayllarda ishlatiladigan dunyo miqyosida noyob identifikatorga ega. Simda har bir SAML protokoli xabarida emitentning identifikatori mavjud.

Autentifikatsiya qilish maqsadida SAML-xabar emitent tomonidan raqamli imzolanishi mumkin. Xabarda imzoni tekshirish uchun xabar qabul qiluvchisi emitentga tegishli bo'lgan ochiq kalitdan foydalanadi. Xuddi shunday, xabarni shifrlash uchun, yakuniy qabul qiluvchiga tegishli bo'lgan umumiy shifrlash kaliti emitentga ma'lum bo'lishi kerak. Ikkala holatda ham imzolash va shifrlashda ishonchli ochiq kalitlarni oldindan bo'lishish kerak.

Xabar imzolangan va shifrlanganidan so'ng, emitent xabarni ishonchli protokolning so'nggi nuqtasiga yuboradi, uning joylashuvi oldindan ma'lum bo'lishi kerak. Qabul qilgandan so'ng, xabar qabul qiluvchisi xabarni parolini ochadi (o'zining shaxsiy shifrini ochish kalitidan foydalangan holda) va imzo tasdiqlaydi (metama'lumotlarda ishonchli ochiq kalit yordamida) ishonchli sherikga xabardagi korxona identifikatorini solishtirishdan oldin.

Oldingi stsenariy har bir tomonni boshqasini oldindan bilishini talab qiladi. Ishonch bazasini o'rnatish uchun tomonlar metama'lumotlarni bir-birlari bilan bo'lishadilar. Dastlab, bu elektron pochta orqali ma'lumot almashish kabi oddiy bo'lishi mumkin. Vaqt o'tishi bilan, SAML sheriklari soni ortib borishi bilan, tabiiy ravishda metama'lumotlarni almashish jarayonini avtomatlashtirish tendentsiyasi paydo bo'ladi.

Metadata almashish jarayonini to'liq avtomatlashtirish uchun standart fayl formatiga ehtiyoj bor. Shu maqsadda SAML V2.0 metadata spetsifikatsiyasi[OS 1] SAML dasturining konfiguratsiyasini soddalashtiradigan va metama'lumotlarni almashish uchun xavfsiz, avtomatlashtirilgan jarayonlarni yaratishga imkon beradigan SAML metama'lumotlari uchun standart vakolatni belgilaydi.

Meta-ma'lumotlarga asoslangan o'zaro bog'liqlik

SAML texnologiyasi pishib yetgan sari SAML metama'lumotlarining ahamiyati doimiy ravishda oshib bordi. Bugungi kunda SAML veb-brauzerini qo'llab-quvvatlovchi dastur bitta tizimga kirish har bir SAML sherigi uchun sxemaga asoslangan SAML metadata faylini talab qiladi. (SAML V2.0 profillariga qarang[OS 2] SAML veb-brauzeri SSO haqida ko'proq ma'lumot olish uchun spetsifikatsiya.)

Stam metadata konfiguratsiyasiga ega bo'lgan SAML veb-brauzer SSO

Statik metadata konfiguratsiyasi

Atama statik metama'lumotlar to'g'ridan-to'g'ri administrator tomonidan SAML dasturida tuzilgan metadata faylini anglatadi. Bunda ma'mur, avvalo qanday metama'lumotlarni olishidan qat'i nazar, metama'lumotlarni saqlash uchun javobgar bo'ladi. Shunday qilib statik metama'lumotlar SAML dasturining umumiy statik konfiguratsiyasiga hissa qo'shadi.

Afsuski, SAML metama'lumotlari tabiatan statik emas, chunki ular orasida quyidagi odatiy stsenariy tasvirlangan SAML identifikatori provayderi (IdP) va a SAML xizmat ko'rsatuvchi provayderi (SP). IdP egasi SP sherigidan SAML metama'lumotlarini olsin deylik. Ehtimol, SP metadata IdP egasiga elektron pochta orqali uzatilishi mumkin, yoki IdP egasi himoyalangan veb-ilovaga kirib, brauzer orqali SP metadata-ni yuklab olishi mumkin. Metadata qanday olinishidan qat'i nazar, yakuniy natija bir xil: IdP egasi SP metama'lumotlarini to'g'ridan-to'g'ri IdP dasturiga sozlaydi.

Endi SP metadata ochiq shifrlash kalitini o'z ichiga oladi. Ehtimol, tegishli shaxsiy parol hal qilish kaliti SP dasturida tuzilgan. Agar shaxsiy shifrni ochish kaliti buzilgan bo'lsa (yoki boshqa usul bilan o'zgartirilishi kerak bo'lsa), SP meta-ma'lumotidagi umumiy shifrlash kaliti endi ishonchli emas va uni almashtirish ham kerak.

SP metama'lumotlari IdP dasturida statik tarzda tuzilganligi sababli, SP metamalumotlaridagi umumiy shifrlash kalitini faqat IdP egasi almashtirishi mumkin. Shu ma'noda, Ma'lumotlar bazasi egasi SP metadata uchun javobgardir. Ushbu mos kelmaslik o'zaro muvofiqlik masalalariga olib keladi.

Xuddi shu narsa SP tomonida ham amal qiladi. IdP meta-ma'lumotlarini SP dasturiy ta'minotiga statik ravishda sozlash orqali, SP egasi, biror narsa o'zgarganda, IdP meta-ma'lumotlarini saqlash uchun javobgarlikni bevosita qabul qiladi. IdP (yoki SP) odatda ko'plab sheriklarga ega bo'lganligi sababli, statik metama'lumotlar konfiguratsiyasi aniq miqyosga ega emas va bundan tashqari, statik metama'lumotlar bilan bog'liq o'zgarishlarni boshqarish eng yaxshi darajada qiyin.

Avtomatik metadata almashinuvi bilan SAML veb-brauzer SSO

Dinamik metadata almashinuvi

Metadata almashish jarayonlari avtomatlashtirilishini istashlari ajablanarli emas. Ma'mur tomonidan SAML dasturida statik ravishda tuzilgan har bir metadata fayli texnik qarzga ega. Ushbu qarzning to'planishi SAML-ning tarqalishini potentsialiga qarab kengayishiga yo'l qo'ymaydi.

Haddan tashqari texnik qarzni oldini olish uchun metama'lumotlarni almashish jarayoni avtomatlashtirilgan bo'lishi kerak. Yondashuvlardan biri - metamahlumotlarni yig'ish, boshqarish va tarmoq bo'ylab tarqatish uchun javobgar bo'lgan ishonchli uchinchi tomonning yordamiga murojaat qilishdir. Kiritilgan metama'lumotlar doimiy ravishda formatlangan bo'lib, zaifliklarga ega emas (qasddan yoki boshqacha) va shuning uchun ulardan foydalanish xavfsizdir.

SAML metama'lumotlari bo'lsa, bu ishonchli uchinchi tomon a deb nomlanadi SAML federatsiyasi. Federatsiyani o'z ichiga olgan SAML tarqatuvchilar jamoasi o'zaro hamkorlik va ishonchni rivojlantirish uchun SAML-ning bir yoki bir nechta profillariga tayyor holda mos keladi. Shu maqsadda federatsiya ishtirokchilari tez-tez metamalumotlarni almashish uchun markaziy infratuzilmani baham ko'rishadi, bu federatsiyaga minglab o'zaro hamkorlik qilish mumkin bo'lgan SAML tarqatish imkoniyatlarini beradi.

SAML metama'lumotlari tarixi

Keling, 2005 yil mart oyida SAML V2.0 metadata spetsifikatsiyasining nashr etilishiga olib kelgan ba'zi bir qadamlarni takrorlaymiz. 2003 yil 14 noyabrda burilish yuz berdi - bizning hikoyamiz shu erda boshlanadi.

Tarixiy kelib chiqishi

Bunga javoban Microsoft Passport, Ozodlik alyansi homilador bo'lgan Identifikatsiya federatsiyasi asoslari, federatsiya texnologiyasi 2002 yildan 2004 yilgacha bo'lgan uch yil davomida ishlab chiqilgan. (Yuqorida aytib o'tilgan SAML tarixi ID-FF uchun kontekstni taqdim etadi.) 2003 yil 14 noyabrda, Ozodlik OASISga ID-FF 1.2 ni qo'shdi. Hissa tarkibiga hujjat kiritilgan Ozodlik metama'lumotlari tavsifi va kashf etilishining 1.0 versiyasi,[LibertyMeta 1] quyidagi dizayn maqsadlarini o'z ichiga olgan:

  1. "whois for SAML federations" (asosida Tashkilot va Bog'lanish uchun shaxs metadatadagi elementlar)
  2. metama'lumotlarni dinamik ravishda kashf qilish (DNS va yaxshi ma'lum bo'lgan manzil orqali aniqlik bilan)
  3. XML imzo yordamida hujjat darajasidagi xavfsizlik

Ma'lum bo'lishicha, ushbu maqsadlarning barchasi ushbu maqolada keyinroq tasvirlangan OASIS SAML V2.0 Metadata Standard-da saqlanib qolgan.

Bilan kiritilgan sxema hujjati Liberty ID-FF 1.2 arxivi Liberty Metadata Version 1.1, Liberty Metadata Version 1.0 esa OASISga o'z hissasini qo'shgan. Ko'rinib turgan ziddiyatni sxema muallifi izohladi. (Piter Devis, Shaxsiy aloqa) 2003 yil noyabr (1.0 versiyasi OASISga qo'shilganida) va 2004 yil dekabrida (1.1 versiyasi Ozodlik tomonidan yakunlanganda), Ozodlik metama'lumotlarini ishlab chiqish OASIS ish oqimiga parallel ravishda davom etdi. Vizual tasvir uchun quyidagi jadvalga qarang. Diagrammadagi strelkalar bog'liqlikni, kesilgan chiziqlar esa tenglikni bildiradi.

SAML metama'lumotlarga bog'liqlik

Muvofiq ma'lumotnomalar Ozodlik ish oqimiga ushbu maqolaning oxirida keltirilgan. OASIS-ga qo'shilgan dastlabki metadata sxemasi Liberty Metadata Version 1.0 ning 7-qismida to'liq keltirilgan.[LibertyMeta 1] spetsifikatsiya. Xuddi shunday, Liberty Metadata Version 1.1 uchun spetsifikatsiya[LibertyMeta 2] 1.1 versiyasi sxemasi ro'yxatini o'z ichiga oladi. Ikkalasi ham 1.0 versiyasi sxemasi va 1.1-versiya sxemasi bu erda Internet Arxivining Wayback Machine-ning iltifoti bilan bog'liq.

2003 yil noyabrdan keyin

Keyingi o'n uch oy davomida, 2003 yil noyabrdan 2004 yil dekabrgacha, OASIS Xavfsizlik Xizmatlari (SAML) Texnik Qo'mitasi (SSTC) Ozodlik metama'lumotlarini spetsifikatsiyasini oxir-oqibat SAML metadata deb atashga muvaffaq bo'ldi. O'sha vaqt mobaynida SSTC metamalumotlarni bir nechta protokollarni (shu jumladan SAML bo'lmagan protokollarni) qo'llab-quvvatlashni o'z ichiga olgan spetsifikatsiyani umumlashtirdi, ammo eng muhimi, Liberty metama'lumotlari sxemasi ko'plab kengaytma punktlari bilan jihozlangan edi. Tarixiy jihatdan SAML meta-ma'lumotlarining kengayishi muhim oqibatlarga olib keldi, biz ko'rib turganimizdek.

2004 yil mart oyiga kelib Ozodlik hissasining katta qismi OASIS ish oqimiga qo'shildi.[SAMLMeta 1] Shu vaqtdan boshlab Ozodlik va OASIS ish oqimlari bir vaqtning o'zida rivojlanib bordi (lekin mustaqil ravishda emas, chunki bir xil odamlar ikkala spetsifikatsiya ustida ishlaganlar). 2004 yil mart va iyul oylari oralig'ida yangi paydo bo'lgan SAML metadata spetsifikatsiyasi jiddiy o'zgarishlarga duch keldi.

2004 yil iyul oyida SSTC a sharhlar uchun ommaviy qo'ng'iroq SAML V2.0 loyihasi texnik xususiyatlarining to'liq to'plamini qamrab olgan. Ushbu spetsifikatsiya to'plamiga yangi soxtalashtirilgan SAML V2.0 Metadata spetsifikatsiyasining ishchi loyihasi kiritilgan.[SAMLMeta 2]

Orqaga qaraganda, SAML V2.0 metadata spetsifikatsiyasining asosiy qismi 2004 yil mart va iyul oylari orasida ishlab chiqilganga o'xshaydi, ammo aniq SAML V2.0 Metadata Standard Liberty Alliance, xususan Liberty Metadata Version 1.0 versiyasidan chiqqan.[LibertyMeta 1] Binobarin, SAML metama'lumotlarining kelib chiqishini tushunish uchun Ozodlik metama'lumotlarining tasdiqlanishini o'rganish kerak.

SAML meta-ma'lumotlarining qolgan tarixi asosan OASIS ma'muriy jarayonidir. 2004 yil noyabr oyida yakuniy qo'mita loyihasi nashr etilgandan so'ng,[SAMLMeta 3] SSTC standartlashtirish jarayonini 2005 yil yanvar oyida boshlagan. Nihoyat, 2005 yil 5 martda OASIS yangi tasdiqlangan SAML V2.0 standartini e'lon qildi.

V2.0 spetsifikatsiyasi to'plami (ga qarang Adabiyotlar to'liq ro'yxat uchun bo'lim) oxirgi SAML V2.0 metadata spetsifikatsiyasini o'z ichiga olgan.[OS 1] O'n yil o'tgach, 2015 yil sentyabr oyida OASIS qayta ko'rib chiqilgan SAML metadata spetsifikatsiyasini xatolar bilan nashr etdi.[OS 3] Natijada, asl metama'lumotlar spetsifikatsiyasi, shuningdek, dastlabki 2.0 spetsifikatsiyalar to'plamidagi boshqa hujjatlar bekor qilingan.

O'tgan o'n yil ichida, 2005 yildan 2015 yilgacha, SSTC bir qator "Post-V2.0" texnikaviy loyihalarini ishlab chiqdi. Ushbu hujjatlar loyihalaridan ba'zilari Qo'mitaning texnik shartlariga aylandi. Ushbu Qo'mita spetsifikatsiyalarining tanlangan pastki qismi Adabiyotlar ushbu maqolaning oxiridagi bo'lim.

2003 yil noyabrgacha

Ma'lum bo'lishicha, Ozodlik identifikatsiyasi federatsiyasi ramkasining SAML metama'lumotlariga ta'siri ID-FF 1.2 ning 2003 yil noyabr oyida qo'shgan hissasidan oldin paydo bo'lgan. Ko'rinishidan, SSTC Liberty alyansi bilan parallel ravishda metamalumotlarga aralashgan. 2003 yil sentyabr oyida nashr etilgan metama'lumotlar spetsifikatsiyasi loyihasidan bir parcha quyidagicha dalolat beradi:

Ushbu hujjat SAML veb-brauzerining SSO profillaridan foydalanish uchun zarur bo'lgan elementlar va atributlarni tavsiflovchi metama'lumotlarni belgilaydi. Liberty Alliance veb-SSO profillari to'g'ridan-to'g'ri SAML veb-SSO profillariga asoslanganligi sababli, ushbu hujjatda belgilangan metama'lumotlar Liberty Alliance 1.2 spetsifikatsiyalari loyihasidagi metama'lum ta'riflaridan katta miqdorda qarz oladi. ("SAML 2.0 veb-brauzerining SSO profillari uchun metadata" dan olingan)[SAMLMeta 4])

Ushbu hujjat loyihasining oxiridagi reviziya tarixi o'zining o'ziga xos xususiyatini beradi: "SAML 1.1 metadata spetsifikatsiyasining 07-chi loyihasi asosida dastlabki loyiha." Boshqacha qilib aytganda, avvalgi hujjatlar loyihalari nashr etilgan. Darhaqiqat, avvalgi qoralama oxirida qayta ko'rib chiqish tarixi[SAMLMeta 5] 2002 yil noyabridan boshlangan metadata spetsifikatsiyalarining izini ko'rsatadi.

Hujjatlar izidan so'ng, Ozodlik ID-FF ning SAML metama'lumotlariga ta'siri 2003 yil aprel oyida chop etilgan spetsifikatsiya loyihasida kuzatilishi mumkin.[SAMLMeta 6] Bu Liberty ID-FF, xususan Liberty Metadata Version 1.0-06 versiyasiga murojaat qilgan birinchi OASIS hujjati,[LibertyMeta 3] Liberty metadata spetsifikatsiyasining dastlabki versiyasi, bu haqda juda kam narsa ma'lum. Shunga qaramay, "SAML 1.1 veb-brauzer profillari uchun metadata" SAML V1.1 standartiga sherik bo'lish uchun mo'ljallangan edi, ammo, albatta, biz V1.1-da metama'lumotlardan foydalanishni aniqlamaganligini bilamiz. Tegishli taxminlar uchun keyingi qismga qarang.

Ikki dastlabki metadata sxemasi qiziq bo'lishi mumkin:

  1. 2002 yil iyun oyida, SSTC SAML V1.0 standartiga aylanishi kerak bo'lgan ishni tugatgandan bir oy o'tgach, Shibbolet loyiha ishlab chiqilgan metadata sxemasi iborat <OriginSite> va <DestinationSite> elementlar. Ushbu sxema Shibboleth IdP dasturining dastlabki versiyalarini boshqaradi.
  1. 2003 yil fevral oyida SSTC "SAML 1.0 veb-brauzer profillari uchun metama'lumotlar" nomli metama'lumotlar spetsifikatsiyasi uchun loyiha sxemasini chiqardi.[SAMLMeta 7] Ushbu sxema qiziquvchan bo'lib qolmoqda, chunki ushbu hujjat oqimining keyingi versiyasi (va keyingi barcha versiyalar) Liberty metadata sintaksisini namoyish etadi.

Metama'lumotlar sxemasini aniqlashga qaratilgan ushbu dastlabki urinishlarning ikkalasi ham Ozodlik metama'lumotlari sxemasining rivojlanishiga sezilarli ta'sir ko'rsatganligini tasdiqlovchi dalillar yo'q.

Tarixiy xulosa

Biz SAML V1.0 yoki SAML V1.1 uchun metadata standartlari hech qachon nashr qilinmaganligini bilamiz. Liberty metadata uchun zarur bo'lgan IPR 2003 yil noyabrgacha mavjud bo'lmaganligini ham bilamiz. Shu bilan biz quyidagi xulosani va taxminni taklif qilamiz:

  1. "SAML 1.0 veb-brauzer profillari uchun metama'lumotlar" nomli spetsifikatsiya loyihasi[SAMLMeta 8] birinchi ma'lum bo'lgan SAML metadata spetsifikatsiyasi edi. Hujjat 2002 yil 12 noyabrda, ya'ni bir hafta keyin SAML V1.0 standarti e'lon qilindi, bu qiziq. Qanday bo'lmasin, ushbu hujjatda ishlatilgan metadata sintaksisi biz SAML metadata deb bilganimizdan butunlay farq qiladi. Ushbu hujjat hech qachon nashr etilmagan va uning kelib chiqishi sir bo'lib qolmoqda.
  2. "SAML 1.1 veb-brauzer profillari uchun metama'lumotlar" nomli spetsifikatsiya loyihasi[SAMLMeta 6] Liberty ID-FF asosida yaratilgan birinchi ma'lum SAML metama'lumotlar spetsifikatsiyasi edi. 2003 yil aprel oyida yakunlandi. Texnik spetsifikatsiya sarlavhasida SSTL SAML V1.1 kelishini va bundan tashqari SAML metama'lumotlari SAML V1.1 standartiga kiritilishi kerakligini bilganligi aniq ko'rsatilgan.
  3. Afsuski, bu sodir bo'lmadi, chunki SAML V1.1 Standard e'lon qilinganida kerakli IPR mavjud emas edi. Haqiqatan ham Ozodlik ID-FF 1.2 ning OASISga rasmiy hissasi ikki oy ichida sodir bo'ldi keyin 2003 yil sentyabr oyida SAML V1.1 standartining e'lon qilinishi.
  4. 2003 yil sentyabr oyida, SAML V1.1 standarti e'lon qilinganidan ikki hafta o'tmasdan, SSTC hujjat oqimini tuzish va hujjat loyihasini qayta nomlash orqali SAML V2.0-ga e'tibor qaratdi: "SAML 2.0 veb-brauzer profillari uchun metadata."[SAMLMeta 4]
  5. SAML metama'lumotlari 2004 yil mart va iyul oylari orasida jonlandi. SSTC a sharhlar uchun ommaviy qo'ng'iroq nomzod SAML metadata spetsifikatsiyasini o'z ichiga olgan.[SAMLMeta 2]
  6. Oxirgi SAML metadata spetsifikatsiyasi[OS 1] 2005 yil mart oyida e'lon qilingan SAML V2.0 standart spetsifikatsiyasi to'plamiga kiritilgan.
  7. Keyingi 10 yil davomida spetsifikatsiya hujjatlari rivojlandi (lekin sxema barqaror bo'lib qoldi). Errata (SAMLMeta20Errata) bilan SAML V2.0 metadata uchun spetsifikatsiya[OS 3]) 2015 yil sentyabr oyida nashr etilgan.

V2.0-dan keyingi texnik xususiyatlar

Avval aytib o'tganimizdek, SAML V2.0 metadata sxemasi[OS 4] ko'plab kengaytma nuqtalariga ega. Ushbu xususiyat "Post-V2.0" spetsifikatsiyalarining ko'payishiga olib keldi, bu standartni bir necha yo'nalishda kengaytirdi. Ommabop metadata kengaytmalari qulayligi uchun quyida keltirilgan (qarang misollar maxsus foydalanish holatlari uchun):

  1. SAML V2.0 Ro'yxatdan o'tish va nashr qilish uchun ma'lumotlarning kengaytmalari 1.0 versiyasi.[CS 1]
  2. Suhbat xususiyatlari uchun SAML V2.0 metadata kengaytmasi.[CS 2]
  3. SAML V2.0 metadata kengaytmalari tizimga kirish va ochish uchun foydalanuvchi interfeysi 1.0 versiyasi.[CS 3]
  4. Shaxsiy identifikatorni kashf qilish bo'yicha xizmat ko'rsatuvchi protokol va profil.[CS 4]
  5. Xizmat ko'rsatuvchi provayderning so'rovini boshlash protokoli va 1.0 versiyasi.[CS 5]
  6. Algoritmni qo'llab-quvvatlash versiyasi 1.0 uchun SAML V2.0 metadata profili.[CS 6]

Muhim "Post-V2.0" spetsifikatsiyasi bu SAML V2.0 metadata o'zaro ishlash profili,[CS 7] bu rasmiy ochiq kalit infratuzilmasi (PKI) nihoyatda murakkab va ba'zi holatlarda echib bo'lmaydigan bo'lishi mumkin (masalan, brauzerga qaragan TLS sertifikatini bekor qilish buzilganligi ma'lum)[Misc 1]). Aslida, Meta-ma'lumotlarning o'zaro ishlashi to'g'risidagi profil SAML federatsiyalari uchun ishlaydigan kalitlarni bekor qilish mexanizmini taqdim etishga urinishdir.

2009 yil avgust oyida nashr etilganidan beri Meta-ma'lumotlarning o'zaro ishlashi to'g'risidagi profil ayniqsa ta'sirli hujjat bo'ldi, ayniqsa oliy ta'limda (masalan, tarqatuvchilar uchun sertifikat bilan bog'liq talablarni ko'ring.)[2 xil] bitta yirik ilmiy-tadqiqot federatsiyasida). Kantara tashabbusi tomonidan nashr etilgan rasmiy dastur profilida metadata bilan o'zaro bog'liqlik muhim rol o'ynaydi:

Amaliyotlar SAML V2.0 Metadata Interoperability Profile tomonidan belgilangan metama'lumotlarning talqin qilinishi va qo'llanilishini qo'llab-quvvatlashi shart. Shundan kelib chiqadiki, dasturlar qo'shimcha ma'lumotlar yoki alohida konfiguratsiyasiz metamalumotlar mavjud bo'lgan har qanday SAML tengdoshlari bilan o'zaro hamkorlik qilishi (standart konfiguratsiya bo'yicha ko'rsatilgandek muvaffaqiyatga yoki muvaffaqiyatsizlikka olib kelishi mumkin).[Boshqa 3]

Darhaqiqat, o'lchovli SAML dasturini ajratib turadigan asosiy xususiyat (bunday bo'lmaganidan) metadata o'zaro muvofiqligi.

SAML metadata misollari

Ushbu bo'limda biz SAMLning aniq misollarini keltiramiz shaxs identifikatori, SAML metama'lumotlaridagi asosiy siyosat va o'zaro muvofiqlik. Misollarning har biri quyidagi metadata bitlarini o'z ichiga oladi:

  • Korxona identifikatori va shaxs atributlari
  • Rolni tavsiflovchi (ikkala tavsiflovchi a SAML identifikatori provayderi yoki a SAML xizmat ko'rsatuvchi provayderi )
    • Foydalanuvchi interfeysi elementlari
    • Imzolash kalitlari yoki shifrlash kalitlari
    • Bitta kirish protokolining so'nggi nuqtalari
  • Ro'yxatdan o'tish va nashr haqida ma'lumot
  • Tashkilot va aloqa ma'lumotlari (odamlarning kitobxonlari uchun)

Quyidagi misollarda metama'lumotlarda ma'lum bir URI (masalan shaxs identifikatori yoki so'nggi manzil manzili) URI domeni komponenti orqali mas'ul tomonga xaritalar:

  • Domenga egalik qiluvchi tashkilot example.info aniqlanmagan SAML ob'ekti uchun javobgardir (masalan, shaxsni tasdiqlovchi yoki xizmat ko'rsatuvchi provayder)
  • Domenga egalik qiluvchi tashkilot example.org a uchun javobgardir SAML identifikatori provayderi
  • Domenga egalik qiluvchi tashkilot example.com a uchun javobgardir SAML xizmat ko'rsatuvchi provayderi
  • Domenga egalik qiluvchi tashkilot example.net metadata ro'yxatdan o'tkazish va nashr etish uchun mas'ul bo'lgan ishonchli uchinchi shaxs

SAML metama'lumotlari brauzer foydalanuvchisidan tashqari metamalumotlarga asoslangan SAML veb-brauzer SSO-ga aloqador barcha tomonlarni tavsiflashini unutmang. (SAML V2.0 profillariga qarang[OS 2] SAML veb-brauzeri SSO haqida ko'proq ma'lumot olish uchun spetsifikatsiya.)

Shaxs metama'lumotlari

Quyidagi kod namunasi SAML-ning umumiy texnik xususiyatlarini aks ettiradi <md:EntityDescriptor> element:

   shaxs identifikatori ="https://sso.example.info/entity" validUntil ="2017-08-30T19: 10: 29Z"    xmlns: md ="urn: voha: ismlar: tc: SAML: 2.0: metadata"    xmlns: saml ="urn: voha: ismlar: tc: SAML: 2.0: tasdiq"    xmlns: mdrpi ="urn: voha: ismlar: tc: SAML: metadata: rpi"    xmlns: mdattr ="urn: oasis: names: tc: SAML: metadata: attribute"    xmlns: ds ="http://www.w3.org/2000/09/xmldsig#">    <!-- insert ds:Signature element (omitted) -->    <md:Extensions>       registerAuthority ="https://registrar.example.net"/>       creatInstant ="2017-08-16T19: 10: 29Z" noshir ="https://registrar.example.net"/>      <mdattr:EntityAttributes>         Ism ="http://registrar.example.net/entity-category" NameFormat ="urn: voha: ismlar: tc: SAML: 2.0: attrname-format: uri">          <saml:AttributeValue>https://registrar.example.net/category/self-certified</saml:AttributeValue>        </saml:Attribute>      </mdattr:EntityAttributes>    </md:Extensions>    <!-- insert one or more concrete instances of the md:RoleDescriptor abstract type (see below) -->    <md:Organization>       xml: lang ="uz">...</md:OrganizationName>       xml: lang ="uz">...</md:OrganizationDisplayName>       xml: lang ="uz">https://www.example.info/</md:OrganizationURL>    </md:Organization>     contactType ="texnik">      <md:SurName>SAML texnik ko'magi</md:SurName>      <md:EmailAddress>mailto: [email protected]</md:EmailAddress>    </md:ContactPerson>  </md:EntityDescriptor>

Ushbu umumiy ob'ektni tavsiflovchi haqida quyidagi tafsilotlarga e'tibor bering:

  • The shaxs identifikatori atribut - bu shaxsning yagona identifikatori. E'tibor bering shaxs identifikatori bu korxona uchun o'zgarmas nom bo'lib, uning joylashuvi emas.
  • The yaroqlilik muddati atribut meta-ma'lumotlarning amal qilish muddatini beradi.
  • The <ds:Signature> elementida (soddaligi uchun chiqarib tashlangan) metamalumotlarning haqiqiyligi va yaxlitligini ta'minlaydigan raqamli imzo mavjud. Imzolovchi a deb nomlangan ishonchli uchinchi shaxs deb hisoblanadi metadata registratori.
  • The <mdrpi:RegistrationInfo> kengaytma elementi[CS 1] metadata registratori uchun identifikatorni tasdiqlaydi.
  • The <mdrpi:PublicationInfo> kengaytma elementi[CS 1] metadata noshirini tasdiqlaydi (bu registrator bilan bir xil bo'ladi). The yaratishInstant atribut metadata yaratilganligining aniq lahzasini beradi. Ning qiymatini taqqoslash yaratishInstant atributi yaroqlilik muddati xususiyati, biz metama'lumotlar ikki hafta davomida amal qilishini ko'ramiz.
  • The <mdattr:EntityAttributes> kengaytma elementi[CS 2] bitta shaxs atributini o'z ichiga oladi. Korxona "o'z-o'zini sertifikatlagan" degan taxminlarni, ehtimol taxmin qilinadigan sifat deb ataydi.
  • Da aniqlangan tashkilot <md:Organization> element ob'ekt identifikatori tomonidan tavsiflangan "ob'ekt uchun javobgardir" (SAMLMeta-ning 2.3.2 qismi)[OS 3]). The <md:Organization> element har bir turdagi bir yoki bir nechta tilga mos bolalar elementlarini o'z ichiga oladi.
  • Bilan aloqa ma'lumotlari <md:ContactPerson> element korxona uchun mas'ul bo'lgan texnik kontaktni aniqlaydi. Bir nechta kontaktlar va aloqa turlari mumkin. SAMLMeta-ning 2.3.2.2 bo'limiga qarang.[OS 3]

Ushbu muhim misolda qisqa muddatli bo'lishi uchun juda muhim rol tavsiflovchisi chiqarib tashlangan. SAML metadata spetsifikatsiyasi .ning ko'plab aniq misollarini aniqlaydi md: RoleDescriptor mavhum turi (SAMLMeta-ning 2.4.1 qismi[OS 3]). Ikkita eng muhim rollarni <md:IDPSSODescriptor> element va <md:SPSSODescriptor> element. Ushbu rol tavsiflovchilarining har biri quyidagi bo'limlarda tasvirlangan.

Shaxsiy identifikatorning metama'lumotlari

A SAML identifikatori provayderi Yagona kirish xizmatining so'nggi nuqtasini boshqaradi[OS 2] xizmat ko'rsatuvchi provayderlardan autentifikatsiya qilish bo'yicha so'rovlarni qabul qiladigan. Ushbu rolda identifikator provayderi uchun shaxs identifikatorida an mavjud <md:IDPSSODescriptor> o'zi kamida bitta narsani o'z ichiga olgan element <md:SingleSignOnService> so'nggi nuqta. Quyidagi misol ikkita ikkita so'nggi nuqtani aks ettiradi:

   shaxs identifikatori ="https://sso.example.org/idp" validUntil ="2017-08-30T19: 10: 29Z"    xmlns: md ="urn: voha: ismlar: tc: SAML: 2.0: metadata"    xmlns: saml ="urn: voha: ismlar: tc: SAML: 2.0: tasdiq"    xmlns: mdrpi ="urn: voha: ismlar: tc: SAML: metadata: rpi"    xmlns: mdattr ="urn: oasis: names: tc: SAML: metadata: attribute"    xmlns: mdui ="urn: voha: ismlar: tc: SAML: metadata: ui"    xmlns: ds ="http://www.w3.org/2000/09/xmldsig#">    <!-- insert ds:Signature element (omitted) -->    <md:Extensions>       registerAuthority ="https://registrar.example.net"/>       creatInstant ="2017-08-16T19: 10: 29Z" noshir ="https://registrar.example.net"/>      <mdattr:EntityAttributes>         Ism ="http://registrar.example.net/entity-category" NameFormat ="urn: voha: ismlar: tc: SAML: 2.0: attrname-format: uri">          <saml:AttributeValue>https://registrar.example.net/category/self-certified</saml:AttributeValue>        </saml:Attribute>      </mdattr:EntityAttributes>    </md:Extensions>     ProtokolSupportEnumeration ="urn: voha: ismlar: tc: SAML: 2.0: protokol">      <md:Extensions>        <mdui:UIInfo>           xml: lang ="uz">Example.org</mdui:DisplayName>           xml: lang ="uz">Example.org da shaxsni tasdiqlovchi provayder</mdui:Description>           balandlik ="32" kenglik ="32" xml: lang ="uz">https://idp.example.org/myicon.png</mdui:Logo>        </mdui:UIInfo>      </md:Extensions>       foydalanish ="imzolash">        <ds:KeyInfo>...</ds:KeyInfo>      </md:KeyDescriptor>       Majburiy ="urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-Redirect" Manzil ="https://idp.example.org/SAML2/SSO/Redirect"/>       Majburiy ="urn: voha: ismlar: tc: SAML: 2.0: birikmalar: HTTP-POST" Manzil ="https://idp.example.org/SAML2/SSO/POST"/>    </md:IDPSSODescriptor>    <md:Organization>       xml: lang ="uz">Example.org notijorat tashkiloti</md:OrganizationName>       xml: lang ="uz">Example.org</md:OrganizationDisplayName>       xml: lang ="uz">https://www.example.org/</md:OrganizationURL>    </md:Organization>     contactType ="texnik">      <md:SurName>SAML texnik ko'magi</md:SurName>      <md:EmailAddress>mailto: [email protected]</md:EmailAddress>    </md:ContactPerson>  </md:EntityDescriptor>

Ning mazmuni <md:IDPSSODescriptor> element identifikatorni etkazib beruvchida yagona kirish xizmatini tavsiflaydi. Ushbu element haqida quyidagi tafsilotlarga e'tibor bering:

  • The <mdui:UIInfo> idish[CS 3] xizmat ko'rsatuvchi provayderda dinamik foydalanuvchi interfeyslarini yaratish uchun ishlatiladigan tilga mos kengaytirilgan elementlar to'plamini o'z ichiga oladi. Xizmat ko'rsatuvchi provayderda eng muhim foydalanuvchi interfeysi bu identifikatorni aniqlash interfeysi.
  • Shaxsiy identifikatorni etkazib beruvchi dasturiy ta'minot shaxsiy SAML imzo kaliti bilan tuzilgan bo'lishi mumkin. Tegishli ochiq kalit <md:KeyDescriptor use="signing"> element. Yuqoridagi misolda asosiy material qisqartirilishi uchun kalit tavsiflovchisidan chiqarib tashlangan.
  • The Majburiy atributlari <md:SingleSignOnService> elementlar SAML 2.0 majburiy spetsifikatsiyasida (SAMLBind) ko'rsatilgan standart URI-lardir[OS 5]).

Ning qiymatlari md: SingleSignOnService / @ Joylashuv identifikator provayderi metama'lumotlaridagi atributlar xizmat ko'rsatuvchi provayder tomonidan SAML-xabarlarni yo'naltirish uchun ishlatiladi, bu esa firibgarlikni tasdiqlovchi provayderni uyushtirishni kamaytiradi o'rtada hujum.

Xizmat ko'rsatuvchi provayderning metama'lumotlari

A SAML xizmat ko'rsatuvchi provayderi Assertion Consumer Service so'nggi nuqtasini boshqaradi[OS 2] identifikator provayderlaridan autentifikatsiya tasdiqlarini olgan. Ushbu rolda xizmat ko'rsatuvchi provayder uchun shaxs identifikatorida an mavjud <md:SPSSODescriptor> o'zi kamida bitta narsani o'z ichiga olgan element <md:AssertionConsumerService> so'nggi nuqta. Quyidagi misolda bunday so'nggi nuqta tasvirlangan:

   shaxs identifikatori ="https://sso.example.com/portal" validUntil ="2017-08-30T19: 10: 29Z"    xmlns: md ="urn: voha: ismlar: tc: SAML: 2.0: metadata"    xmlns: saml ="urn: voha: ismlar: tc: SAML: 2.0: tasdiq"    xmlns: mdrpi ="urn: voha: ismlar: tc: SAML: metadata: rpi"    xmlns: mdattr ="urn: oasis: names: tc: SAML: metadata: attribute"    xmlns: mdui ="urn: voha: ismlar: tc: SAML: metadata: ui"    xmlns: idpdisc ="urn: voha: ismlar: tc: SAML: profillar: SSO: idp-discovery -ocol"    xmlns: ds ="http://www.w3.org/2000/09/xmldsig#">    <!-- insert ds:Signature element (omitted) -->    <md:Extensions>       registerAuthority ="https://registrar.example.net"/>       creatInstant ="2017-08-16T19: 10: 29Z" noshir ="https://registrar.example.net"/>      <mdattr:EntityAttributes>         Ism ="http://registrar.example.net/entity-category" NameFormat ="urn: voha: ismlar: tc: SAML: 2.0: attrname-format: uri">          <saml:AttributeValue>https://registrar.example.net/category/self-certified</saml:AttributeValue>        </saml:Attribute>      </mdattr:EntityAttributes>    </md:Extensions>     WantAssertionsSigned ="rost" ProtokolSupportEnumeration ="urn: voha: ismlar: tc: SAML: 2.0: protokol">      <md:Extensions>        <mdui:UIInfo>           xml: lang ="uz">Example.com sotuvchisi xizmati</mdui:DisplayName>           xml: lang ="uz">https://service.example.com/about.html</mdui:InformationURL>           xml: lang ="uz">https://service.example.com/privacy.html</mdui:PrivacyStatementURL>           balandlik ="32" kenglik ="32" xml: lang ="uz">https://service.example.com/myicon.png</mdui:Logo>        </mdui:UIInfo>         indeks ="0" Majburiy ="urn: voha: ismlar: tc: SAML: profillar: SSO: idp-discovery -ocol" Manzil ="https://service.example.com/SAML2/Login"/>      </md:Extensions>       foydalanish ="shifrlash">        <ds:KeyInfo>...</ds:KeyInfo>      </md:KeyDescriptor>      <md:NameIDFormat>urn: voha: ismlar: tc: SAML: 2.0: nameid-format: vaqtinchalik</md:NameIDFormat>       indeks ="0" Majburiy ="urn: voha: ismlar: tc: SAML: 2.0: birikmalar: HTTP-POST"  Manzil ="https://service.example.com/SAML2/SSO/POST"/>       indeks ="0">         xml: lang ="uz">Example.com xodimlar portali</md:ServiceName>         isRequired ="rost"          NameFormat ="urn: voha: ismlar: tc: SAML: 2.0: attrname-format: uri"          Ism ="urn: oid: 1.3.6.1.4.1.5923.1.1.1.13" FriendlyName ="eduPersonUniqueId"/>                  NameFormat ="urn: voha: ismlar: tc: SAML: 2.0: attrname-format: uri"          Ism ="urn: oid: 0.9.2342.19200300.100.1.3" FriendlyName ="pochta"/>      </md:AttributeConsumingService>    </md:SPSSODescriptor>    <md:Organization>       xml: lang ="uz">Example.com Inc.</md:OrganizationName>       xml: lang ="uz">Example.com</md:OrganizationDisplayName>       xml: lang ="uz">https://www.example.com/</md:OrganizationURL>    </md:Organization>     contactType ="texnik">      <md:SurName>SAML texnik ko'magi</md:SurName>      <md:EmailAddress>mailto: [email protected]</md:EmailAddress>    </md:ContactPerson>  </md:EntityDescriptor>

Ning mazmuni <md:SPSSODescriptor> element xizmat ko'rsatuvchi provayderda Assertion Consumer Service-ni tavsiflaydi. Ushbu element haqida quyidagi tafsilotlarga e'tibor bering:

  • The WantAssertionsSigned xususiyati <md:SPSSODescriptor> element xizmat ko'rsatuvchi provayder xohlaganligini e'lon qiladi <saml:Assertion> raqamli imzolanadigan element. Ushbu atribut metadata xabardor identifikator provayderining ishlash vaqtida o'zini avtomatik ravishda sozlashiga olib keladi.
  • The <mdui:UIInfo> kengaytma elementi[CS 3] identifikator provayderida dinamik foydalanuvchi interfeyslarini yaratish uchun ishlatiladigan tilga mos kengaytirilgan elementlar to'plamini o'z ichiga oladi. Identifikator provayderidagi ikkita muhim foydalanuvchi interfeysi - bu kirish sahifasi va foydalanuvchi roziligi interfeysi.
  • The <idpdisc:DiscoveryResponse> kengaytma elementi[CS 4] identifikatorni kashf qilish bilan birgalikda ishlatiladigan so'nggi nuqtani belgilaydi.
  • Xizmat ko'rsatuvchi dasturiy ta'minot, ehtimol, shaxsiy SAML parolini ochish kaliti bilan tuzilgan. Shifrlash uchun ochiq SAML kaliti <md:KeyDescriptor use="encryption"> element. Yuqoridagi misolda asosiy material qisqartirilishi uchun kalit tavsiflovchisidan chiqarib tashlangan.
  • The <md:NameIDFormat> element kerakli formatni beradi <saml:NameID> SAML tasdiqidagi element. Ushbu elementning mavjudligi metadata xabardor identifikator provayderining ishlash vaqtida o'zini avtomatik ravishda sozlashiga olib keladi.
  • The indeks atributi <md:AssertionConsumerService> elementi qiymati sifatida ishlatiladi AssertionConsumerServiceIndex atributi <samlp:AuthnRequest> element.
  • The Majburiy atributi <md:AssertionConsumerService> element SAML 2.0 majburiy spetsifikatsiyasida (SAMLBind) ko'rsatilgan standart URI[OS 5]).
  • The <md:AttributeConsumingService> elementni shakllantirish uchun identifikator provayder tomonidan ishlatiladi <saml:AttributeStatement> SAML veb-brauzer SSO bilan birgalikda xizmat ko'rsatuvchi provayderga yuborilgan element.
  • The indeks atributi <md:AttributeConsumingService> elementi qiymati sifatida ishlatiladi AttributeConsumingServiceIndex atributi <samlp:AuthnRequest> element.

Ning qiymati md: AssertionConsumerService / @ Manzil xizmat ko'rsatuvchi provayderidagi atribut identifikator provayder tomonidan SAML xabarlarini yo'naltirish uchun ishlatiladi, bu esa yolg'on xizmat ko'rsatuvchi provayderni uyushtirish imkoniyatini minimallashtiradi. o'rtada hujum.

Meta-ma'lumotlarga asoslangan SAML veb-brauzeri

Quyidagi SAML protokoli oqimi SAML veb-brauzer SSO ning turli bosqichlarida metama'lumotlardan foydalanishni tasvirlash uchun mo'ljallangan. (SAML V2.0 profillariga qarang[OS 2] SAML veb-brauzeri SSO haqida ko'proq ma'lumot olish uchun spetsifikatsiya.)

SAML veb-brauzerining ochilishi va kirishi bilan SSO

Ishonchli SAML metama'lumotlari a o'rtasida xavfsiz tranzaktsiyani ta'minlaydi SAML identifikatori provayderi (IdP) va a SAML xizmat ko'rsatuvchi provayderi (SP). Meta-ma'lumotlardan oldin ishonch to'g'risidagi ma'lumotlar mulkiy tartibda dasturga kiritilgan. Endi ishonchli ma'lumot almashish uchun standart metama'lumotlar yordam beradi. SAML 2.0 metadata standarti[OS 3] ishonchli jarayonni yuklash uchun shaxslar foydalanishi mumkin bo'lgan aniq belgilangan, birgalikda ishlaydigan metadata formatini taqdim etadi.

Quyidagi ketma-ketlik SAML protokol oqimini boshqarish uchun SAML metama'lumotlaridan foydalanishni tasvirlaydi.

1. SPda maqsadli resursni so'rang

Brauzer foydalanuvchisi SAML xizmat ko'rsatuvchi provayder tomonidan himoyalangan veb-dastur manbasini so'raydi:

 https://sp.example.com/myresource

Agar foydalanuvchi direktori uchun tegishli xavfsizlik konteksti xizmat ko'rsatuvchi provayderda allaqachon mavjud bo'lsa, 2-13 bosqichlarni o'tkazib yuboring.

2. Discovery xizmatiga yo'naltirish

6-bosqichda xizmat ko'rsatuvchi provayder SAML protokoli oqimini boshlashdan oldin, brauzer foydalanuvchisi afzal ko'rgan shaxs ko'rsatuvchi provayder ma'lum bo'lishi kerak. Buning ko'plab usullari mavjud. Illyustratsiya maqsadida, xizmat ko'rsatuvchi provayder mahalliy Discovery xizmatidan foydalanadi Shaxsiy identifikatorni kashf qilish bo'yicha xizmat ko'rsatuvchi protokol va profil.[CS 4]

Xizmat ko'rsatuvchi provayder foydalanuvchini Discovery xizmatiga yo'naltiradi:

302 yo'naltirishJoylashuv: https://ds.example.com/idpdisc?entityID=https%3A%2F%2Fsso.example.org%2Fportal

E'tibor bering, SP shaxs identifikatori kashfiyot protokoli tomonidan belgilangan yo'naltirish URL-ga kiritilgan.

3. Discovery xizmatiga murojaat qiling

Brauzer foydalanuvchisi yo'naltirish tufayli Discovery xizmatidan so'raydi:

OLING /idpdisc?entityID=https%3A%2F%2Fsso.example.org%2Fportal HTTP/1.1Xost: ds.example.com
Meta-ma'lumotlarda ishonchli xizmat ko'rsatuvchi provayderlar

Discovery Service qanday qilib xizmat ko'rsatuvchi provayder haqiqiyligini biladi va yomon maqsadlar uchun foydalanuvchi identifikatorini o'rganishga urinayotgan yovuz firibgar emas?

Discovery Service ishonchli xizmat ko'rsatuvchi provayderlar ro'yxatiga murojaat qiladi metadata ichida javob berishdan oldin.

(Foydalanuvchining tanlagan IDP-ni kashf eting)

Discovery xizmati ko'rsatilmagan vositalar yordamida brauzer foydalanuvchisi afzal ko'rgan identifikatorni aniqlaydi.

Metadata tarkibidagi foydalanuvchi interfeysi elementlari

Discovery Service mos kashfiyot interfeysini qanday yaratadi?

Discovery Service ishonchli metadata do'koniga murojaat qilib, brauzer foydalanuvchisiga taqdim etish uchun ishonchli identifikator provayderlarining tegishli ro'yxatini aniqlaydi. The <mdui:UIInfo> foydalanuvchi interfeysi elementlari metadata ichida dinamik kashfiyot interfeysini yaratish uchun ishlatilishi mumkin.

4. SPdagi Discovery Response so'nggi nuqtasiga yo'naltirish

Endi Discovery Service brauzer foydalanuvchisini xizmat ko'rsatuvchi provayderda Discovery Response so'nggi nuqtasiga yo'naltiradi:

302 yo'naltirishJoylashuv: https://sp.example.com/SAML2/Login?entityID=https%3A%2F%2Fsso.example.org%2Fidp

IdP-ga e'tibor bering shaxs identifikatori kashfiyot protokoli tomonidan belgilangan yo'naltirish URL-ga kiritilgan.

Meta-ma'lumotlardagi ishonchli so'nggi joylar

Discovery xizmati foydalanuvchini IdP bilan qaerga jo'natishni qaerdan biladi shaxs identifikatori?

Discovery xizmati ishonchli xizmat ko'rsatuvchi provayderning oldindan aniqlangan Discovery Response so'nggi nuqtasini qidiradi metadata ichida.

5. SPda Discovery Response so'nggi nuqtasini so'rang

Brauzer foydalanuvchisi yo'naltirish asosida Discovery Response so'nggi nuqtasini xizmat ko'rsatuvchi provayderdan so'raydi:

OLING /SAML2/Login?entityID=https%3A%2F%2Fsso.example.org%2Fidp HTTP/1.1Xost: sp.example.com

The Discovery Response endpoint at the service provider conforms to the Identity Provider Discovery Service Protocol and Profile.[CS 4]

Trusted identity providers in metadata

How does the service provider know that the identity provider given by the entityID in the discovery protocol URL is authentic and not some evil identity provider trying to phish the user's password?

The service provider consults its list of trusted identity providers in metadata before issuing a SAML Request at the next step. If the service provider can emas determine if the identity provider in question is trusted, the browser user kerak emas be redirected to the IdP. This is why it is imperative that IdP metadata kerak be trusted metadata.

6. Redirect to SSO Service at the IdP

The service provider generates a relevant <samlp:AuthnRequest> element, encodes a SAML Request in an URL query string, and then redirects the browser user to the Single Sign-On Service at the identity provider:

302 yo'naltirishJoylashuv: https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token

For an outline how to construct the query string, see the corresponding SAML protocol flow in the SAML 2.0 article. Refer to SAMLCore[OS 6] tafsilotlar uchun.

Trusted endpoint locations in metadata

How does the service provider know where to send the user with the SAML Request?

The service provider looks up a pre-arranged endpoint location of the trusted identity provider in metadata.

7. Request the SSO Service at the IdP

The browser user requests the Single Sign-On Service endpoint at the identity provider by virtue of the redirect:

OLING / SAML2 / SSO / Redirect? SAMLRequest = request & RelayState = token HTTP/1.1Xost: idp.example.org
Trusted service providers in metadata

How does the identity provider know the service provider is authentic and not some evil service provider trying to harvest shaxsan aniqlanadigan ma'lumotlar regarding the user?

The identity provider consults its list of trusted service providers in metadata before issuing a response.

8. Respond with the login page

The identity provider returns a login page to the user's browser. The login page contains an HTML form similar to the following:

  <shakl usul="post" harakat="https://sp.example.com/login-response" ...>    Username:<br>    <kiritish turi="matn" ism="foydalanuvchi nomi"><br>    Parol:<br>    <kiritish turi="parol" ism="parol">    ...    <kiritish turi="topshirish" qiymat="Yuborish" />  </shakl>
User interface elements in metadata
To reassure the browser user, the IdP personalizes the login page using the <mdui:UIInfo> foydalanuvchi interfeysi elementlari in metadata.

9. Submit the login form

The browser user submits the HTML form to the identity provider:

POST /login-response HTTP/1.1Xost: sp.example.comTarkib turi: application / x-www-form-urlencodedTarkib uzunligi: nnnusername=username&password=password

(Issue a SAML Assertion for the user)

At this point, the identity provider knows the identity of the user principal and so the identity provider constructs a SAML Assertion on behalf of the user principal. For a concrete example of such an Assertion, see the corresponding SAML protocol flow in the SAML 2.0 article. As always, refer to SAMLCore[OS 6] tafsilotlar uchun.

The <saml:NameID> element in the SAML Assertion encodes an identifier for the user principal. In this case, the identity provider includes a SAML2 Transient NameID (SAMLCore[OS 6]) in the SAML Assertion.

NameID format in metadata

Why does the identity provider use a Transient NameID format in the SAML Assertion (as opposed to some other format)?

Faraz qilsak <samlp:AuthnRequest> element issued by the service provider does not request otherwise, a metadata-aware IdP will consult the <md:NameIDFormat> elementlar in metadata (if any) to determine the NameID format.

The identity provider includes two user attributes in the SAML Assertion: eduPersonUniqueId va pochta.

Requested attributes in metadata

Why does the identity provider include attributes eduPersonUniqueId va pochta in the assertion and not some other attributes?

A metadata-aware IdP will consult the <md:RequestedAttribute> elementlar in metadata (if any) to learn the attribute requirements of the service provider.

Operationally, the identity provider digitally signs and encrypts the SAML Assertion, wraps the Assertion in a SAML Response, and then signs the Response object as well. Typically the identity provider signs the Response alone but in this case both the Assertion and the Response are digitally signed.

WantAssertionsSigned attribute in metadata

How does the identity provider know that the service provider wants the Assertion itself to be digitally signed?

At run time, the identity provider observes that the WantAssertionsSigned XML attribute in metadata is set to true.
Trusted encryption certificate in metadata

How does the identity provider encrypt the SAML Assertion so that the service provider (and only the service provider) can decrypt it?

At run time, the identity provider uses the service provider's encryption certificate in metadata to encrypt the Assertion.

10. Respond with the SAML Response page

The identity provider returns an XHTML document to the user's browser. The document contains a SAML Response encoded in an XHTML form as follows:

  <shakl usul="post" harakat="https://sp.example.com/SAML2/SSO/POST" ...>    <kiritish turi="yashirin" ism="SAMLResponse" qiymat="javob" />    <kiritish turi="yashirin" ism="RelayState" qiymat="nishon" />    ...    <kiritish turi="topshirish" qiymat="Yuborish" />  </shakl>
Trusted endpoint locations in metadata

How does the identity provider know where to send the user with the SAML Response?

The identity provider looks up a pre-arranged endpoint location of the trusted service provider in metadata.

11. Request the Assertion Consumer Service at the SP

The XHTML form is automatically submitted by the browser (due to a small bit of JavaScript on the page):

POST / SAML2 / SSO / POST HTTP/1.1Xost: sp.example.comTarkib turi: application / x-www-form-urlencodedTarkib uzunligi: nnnSAMLResponse = response & RelayState = token
Trusted signing certificate in metadata

How does the service provider know that the SAML Response came from a trusted identity provider?

The service provider verifies the digital signature on the Response using the public key of the identity provider in metadata. After decrypting the signature on the Assertion object, the service provider verifies the signature on the Assertion as well.

12. Redirect to the target resource

The service provider creates a security context for the user principal and redirects the browser user to the original web application resource:

302 yo'naltirishLocation: https://sp.example.com/myresource

13. Request the target resource at the SP again

Finally the browser user requests the target resource at the service provider by virtue of the redirect:

 https://sp.example.com/myresource

14. Respond with requested resource

Since a security context exists, the service provider returns the resource to the browser user agent as requested.

Shuningdek qarang

Adabiyotlar

Liberty metadata specifications

Note: The Liberty metadata schema are listed verbatim in the specification documents listed below. Since the direct link to the Version 1.1 XSD document on the Liberty web site is broken, a copy of the XSD document for Liberty Metadata Version 1.1 has been uploaded to the web. That document is also included in the legacy Liberty ID-FF 1.2 archive.

  1. ^ a b v P. Davis (Editor). Liberty Metadata Description and Discovery Specification. Version 1.0, 12 November 2003. Document identifier: liberty-metadata-v1.0. http://www.projectliberty.org/liberty/content/download/2024/13989/file/liberty-metadata-v1.0.pdf
  2. ^ P. Davis (Editor). Liberty Metadata Description and Discovery Specification. Version 1.1, 14 December 2004. Document identifier: liberty-metadata-v1.1. http://www.projectliberty.org/liberty/content/download/1224/7973/file/liberty-metadata-v1.1.pdf
  3. ^ P. Davis (Editor). Liberty Metadata Description and Discovery Specification. Draft Version 1.0-06, 13 April 2003.

SAML metadata specifications pre-2005

  1. ^ J. Moreh and S. Cantor (Editors). Metadata for SAML 2.0. Working Draft 01, 15 March 2004. Document ID sstc-saml-Metadata-2.0-draft-01.
  2. ^ a b J. Moreh et al. (tahrirlovchilar). Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0. Last-Call Working Draft 08, 13 July 2004. Document ID sstc-saml-metadata-2.0-draft-08. http://xml.coverpages.org/SSTC-SAMLMetadataV20Draft08-7750.pdf (https://drive.google.com/file/d/0B7vociYknAbCelh1TmhjRVBZdmc/view?usp=sharing )
  3. ^ J. Moreh et al. (tahrirlovchilar). Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0. Committee Draft 02e, 11 November 2004. Document ID sstc-saml-metadata-2.0-cd-02e. https://www.oasis-open.org/committees/download.php/10037/sstc-saml-metadata-2.0-cd-02e.pdf
  4. ^ a b J. Moreh (Editor). Metadata for SAML 2.0 Web Browser SSO Profiles. Working Draft 00, 15 September 2003. Document ID sstc-saml-metadata-2.0-draft-00. https://www.oasis-open.org/committees/download.php/4538/sstc-saml-metadata-2.0-draft-00.pdf
  5. ^ J. Moreh et al. (tahrirlovchilar). Metadata for SAML 1.1 Web Browser Profiles. Working Draft 07, 23 July 2003. Document ID sstc-saml-meta-data-draft-07. https://www.oasis-open.org/committees/download.php/3002/draft-sstc-saml-meta-data-07.doc (https://drive.google.com/file/d/0B7vociYknAbCRUJ6UzNuTnNiOW8/view?usp=sharing )
  6. ^ a b J. Moreh et al. (tahrirlovchilar). Metadata for SAML 1.1 Web Browser Profiles. Working Draft 02, 23 April 2003. Document ID draft-sstc-saml-meta-data-02. https://www.oasis-open.org/committees/download.php/1735/draft-sstc-saml-meta-data-02.doc (https://drive.google.com/file/d/0B7vociYknAbCYTFRYVdWcGx1Qlk/view?usp=sharing )
  7. ^ P. Mishra et al. (tahrirlovchilar). Metadata for SAML 1.0 Web Browser Profiles. Working Draft 01, 1 February 2003. Document ID draft-sstc-saml-meta-data-01. http://www.oasis-open.org/committees/security/docs/draft-sstc-saml-meta-data-01.pdf (https://drive.google.com/file/d/0B7vociYknAbCLTJWY0p3bXFYS1E/view?usp=sharing ) https://www.oasis-open.org/committees/security/docs/draft-sstc-schema-meta-data-01.xsd
  8. ^ P. Mishra (editor). Metadata for SAML 1.0 Web Browser Profiles. Working Draft 00, 12 November 2002. Document ID draft-sstc-saml-meta-data-00. http://www.oasis-open.org/committees/security/docs/draft-sstc-saml-meta-data-00.pdf (https://drive.google.com/file/d/0B7vociYknAbCNEZIaDVwaWhXLUU/view?usp=sharing )

SAML standards

The original SAML V2.0 standards published in March 2005 have been eskirgan in favor of the revised specifications with errata listed further below.

Except for historical references to the original SAML V2.0 Metadata Standard, the following footnotes point to SAML V2.0 specifications with errata. The latter specifications are fully inclusive of all errata approved by the OASIS Security Services (SAML) Technical Committee since the SAML V2.0 standards were published in March 2005. Please refer to the OASIS SAML Wiki for the most recent version of any SAML specification.

  1. ^ a b v S. Cantor et al. Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS Standard, March 2005. Document ID saml-metadata-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
  2. ^ a b v d e J. Xyuz va boshq. Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 – Errata Composite. Working Draft 07, 8 September 2015. Document ID sstc-saml-profiles-errata-2.0-wd-07 https://www.oasis-open.org/commmissions/download.php/56782/sstc-saml-profiles-errata-2.0-wd-07.pdf
  3. ^ a b v d e f S. Cantor et al. Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 – Errata Composite. Working Draft 05, 8 September 2015. Document ID sstc-saml-metadata-errata-2.0-wd-05 https://www.oasis-open.org/committees/download.php/56785/sstc-saml-metadata-errata-2.0-wd-05.pdf
  4. ^ Metadata Schema for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS Standard, March 2005. Document ID saml-schema-metadata-2.0 http://docs.oasis-open.org/security/saml/v2.0/saml-schema-metadata-2.0.xsd
  5. ^ a b S. Cantor et al. Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0 – Errata Composite. Working Draft 06, 8 September 2015. Document ID sstc-saml-bindings-errata-2.0-wd-06 https://www.oasis-open.org/committees/download.php/56779/sstc-saml-bindings-errata-2.0-wd-06.pdf
  6. ^ a b v S. Cantor et al. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 – Errata Composite. Working Draft 07, 8 September 2015. Document ID sstc-saml-core-errata-2.0-wd-07 http://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf

Committee specifications post-2005

This is a small subset of the "Post-V2.0" committee specifications published by the OASIS Security Services (SAML) Technical Committee. Iltimos, ga murojaat qiling OASIS SAML Wiki for the most recent version of any SAML specification.

  1. ^ a b v d SAML V2.0 Metadata Extensions for Registration and Publication Information Version 1.0. OASIS Security Services (SAML) Technical Committee Specification 01, 03 April 2012. https://wiki.oasis-open.org/security/SAML2MetadataDRI
  2. ^ a b SAML V2.0 Metadata Extension for Entity Attributes. OASIS Security Services (SAML) Technical Committee Specification 01, 4 August 2009. https://wiki.oasis-open.org/security/SAML2MetadataAttr
  3. ^ a b v SAML V2.0 Metadata Extensions for Login and Discovery User Interface Version 1.0. OASIS Security Services (SAML) Technical Committee Specification 01, 03 April 2012. https://wiki.oasis-open.org/security/SAML2MetadataUI
  4. ^ a b v d Identity Provider Discovery Service Protocol and Profile. OASIS Security Services (SAML) Technical Committee Specification 01, 27 March 2008. https://wiki.oasis-open.org/security/IdpDiscoSvcProtonProfile
  5. ^ Service Provider Request Initiation Protocol and Profile Version 1.0. OASIS Security Services (SAML) Technical Committee Specification 01, 5 November 2010. https://wiki.oasis-open.org/security/RequestInitProtProf
  6. ^ SAML V2.0 Metadata Profile for Algorithm Support Version 1.0. OASIS Security Services (SAML) Technical Committee Specification 01, 21 February 2011. https://wiki.oasis-open.org/security/SAML2MetadataAlgSupport
  7. ^ SAML V2.0 Metadata Interoperability Profile. OASIS Security Services (SAML) Technical Committee Specification 01, 4 August 2009. https://wiki.oasis-open.org/security/SAML2MetadataIOP

Turli xil

  1. ^ Hanno Böck. The Problem with OCSP Stapling and Must Staple and why Certificate Revocation is still broken. 19 may 2017 yil. https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html
  2. ^ SAML Certificates in Federation Metadata. InCommon Federation. https://spaces.internet2.edu/x/boY0
  3. ^ SAML V2.0 Implementation Profile for Federation Interoperability. Kantara Initiative. https://kantarainitiative.github.io/SAMLprofiles/fedinterop.html