Kapag ang mga empleyado ay nag-access ng maraming enterprise application, ang pamamahala ng magkakahiwalay na kredensyal at proseso ng pagpapatotoo ay maaaring maging mahirap para sa mga IT team. Ang mga organisasyon ay nangangailangan ng isang paraan upang maisentro ang pagpapatotoo nang hindi kinakailangang mag-sign in nang hiwalay ang mga user sa bawat application.
Ang SAML (Security Assertion Markup Language) ay isang pamantayang federasyon na nakabatay sa XML na karaniwang ginagamit para sa browser-based single sign-on (SSO). Sa isang tipikal na SAML 2.0 login, pinapatunayan ng isang identity provider ang user at ipinapadala sa application ang isang tugon ng SAML na naglalaman ng isang assertion. Bine-verify ng application ang kinakailangang lagda at iba pang mga kundisyon bago gumawa ng sarili nitong session.
Para sa mga IT at identity administrator, ang pag-unawa kung paano gumagana ang SAML ay makakatulong sa kanila na matukoy kung kailan ito gagamitin, mai-configure nang tama ang mga ugnayan ng tiwala, at maiba ang mga pagkabigo sa pagpapatotoo mula sa mga problema sa account o pahintulot.
Key Takeaways
- SAML ay isang pamantayang nakabatay sa XML na nagbibigay-daan sa federated authentication at single sign-on sa mga compatible na application.
- SAML SSO Gumagamit ang isang identity provider (IdP) upang patunayan ang mga gumagamit at isang service provider (SP) upang patunayan ang mga assertion.
- Sinusuportahan ng SAML ang mga daloy ng pag-login na pinasimulan ng SP at IdP, bawat isa ay may iba't ibang konsiderasyon sa seguridad.
- Ligtas na pagpapatupad ng SAML nangangailangan ng pagpapatunay ng assertion, mga pinagkakatiwalaang configuration, at pamamahala ng certificate. Hindi awtomatikong pinangangasiwaan ng SAML ang awtorisasyon o provisioning ng application.
Ano ang SAML?
Pinapayagan ng SAML ang dalawang organisasyon o sistema na magpalitan ng impormasyon sa pagpapatotoo nang hindi ibinabahagi ang password ng application ng user. Nagtatatag ito ng ugnayan ng tiwala sa pagitan ng:
- An identity provider (IdP) na nagpapatotoo sa gumagamit
- Isang service provider (SP) na nagpapatakbo ng application na gustong i-access ng user
Ang IdP ay naglalabas ng isang XML na dokumento na tinatawag na SAML assertion. Ang assertion ay maaaring tukuyin ang user, ilarawan kung paano o kailan naganap ang authentication, at magdala ng mga katangian tulad ng email address, departamento, o pagiging miyembro ng grupo. Ang SP ay umaasa lamang sa assertion pagkatapos masuri na ito ay nagmula sa isang pinagkakatiwalaang IdP at balido para sa application na iyon at pagtatangka sa pag-login.
Ang kaayusang ito ay isang uri ng pederasyon ng pagkakakilanlan: ang aplikasyon ay nagtatalaga ng authentication sa isang panlabas na awtoridad sa pagkakakilanlan. Maaari nitong bigyan ang mga user ng access sa maraming aplikasyon pagkatapos mag-sign in sa pamamagitan ng IdP, bagama't ang bawat aplikasyon ay lumilikha at namamahala pa rin ng sarili nitong sesyon.
SAML 2.0 ang bersyong ginamit para sa browser SSO mga daloy na inilarawan dito. Maaaring ihatid ng SAML ang pagkakakilanlan at authentication impormasyon, ngunit hindi nito tinutukoy ang isang unibersal na modelo ng pahintulot sa aplikasyon.
Sino at ano ang mga kalahok sa isang SAML login?
Gumagamit, browser, tagapagbigay ng pagkakakilanlan, at tagapagbigay ng serbisyo
Apat na kalahok ang mahalaga sa pag-login sa SAML browser:
- Gumagamit: Ang taong sumusubok na magbukas ng isang application.
- Browser: Ang tagapamagitan na nagdadala ng mga kahilingan at tugon ng SAML sa pagitan ng IdP at SP. Karaniwang inililipat ng browser ang mga mensahe sa pamamagitan ng mga pag-redirect at pagsusumite ng form.
- Tagapagbigay ng pagkakakilanlan: Ang sistemang nag-a-authenticate sa user. Maaari nitong suriin ang password, certificate, security key, o iba pang salik, o kilalanin ang isang umiiral na IdP session.
- Tagapagbigay ng serbisyo: Ang application na kumukuha ng resulta ng SAML. Pagkatapos itong ma-validate, ang SP ang magpapasya kung gagawa ng sesyon ng application at kung ano ang maaaring i-access ng user.
Karaniwang hindi ipinapadala ng IdP ang password ng user sa SP. Sa halip, nagpapadala ito ng isang nilagdaang pahayag na maaaring beripikahin ng SP sa ilalim ng kanilang paunang na-configure na ugnayan ng tiwala.
Kahilingan sa Pag-awtorisasyon, tugon, pagpapatibay, at sesyon ng aplikasyon
Lumilitaw ang ilang kaugnay na artifact habang naglo-login:
- Kahilingan sa Pagpapahintulot: Isang mensahe mula sa SP na humihiling sa IdP na i-authenticate ang isang user. Maaari itong magsama ng pagkakakilanlan ng SP, lokasyon ng pagbabalik, at konteksto ng hiniling na authentication.
- Tugon ng SAML: Ang tugon ng protocol ng IdP sa SP. Iniuulat nito ang tagumpay o pagkabigo at, para sa isang matagumpay na pag-login, karaniwang naglalaman ng isang assertion.
- Pahayag ng SAML: Isang pahayag na may limitadong oras na inilabas ng IdP tungkol sa user. Maaari itong maglaman ng pahayag ng pagpapatotoo, mga katangian, at mga paghihigpit na tumutukoy kung saan at kailan ito maaaring tanggapin.
- Sesyon ng aplikasyon: Ang sariling naka-log in na sesyon ng SP, kadalasang kinakatawan ng isang secure na cookie ng aplikasyon. Ito ay hiwalay sa assertion at sa sesyon ng user sa IdP.
Ang isang SAML assertion ay hindi nilayong magsilbing isang permanenteng sesyon ng aplikasyon. Pinapatunayan ito ng SP, ginagamit ito, at pagkatapos ay inilalapat ang sarili nitong mga kontrol sa sesyon.
Paano gumagana ang SAML single sign-on?
Paano gumagana ang SAML SSO na sinimulan ng SP
Sa SSO na pinasimulan ng service provider, magsisimula ang user sa application:
- Binuksan ng user ang application. Walang nakitang wastong lokal na sesyon ng application ang SP.
- Ang SP ay lumilikha ng isang AuthnRequest. Ire-redirect nito ang browser sa IdP, karaniwang ginagamit ang HTTP-Redirect binding.
- Pinapatunayan ng IdP ang user. Maaaring humingi ang IdP ng mga kredensyal at multifactor authentication, o maaari nitong makilala ang isang umiiral na sesyon ng IdP.
- Ang IdP ay lumilikha ng tugon ng SAML. Ang tugon ay karaniwang naglalaman ng isang pahayag na tumutukoy sa gumagamit at naglalarawan sa kaganapan ng pagpapatotoo.
- Isinusumite ng browser ang tugon sa SP. Karaniwang nangyayari ito sa pamamagitan ng isang awtomatikong isinumiteng HTML form na ipinapadala sa Assertion Consumer Service (ACS) URL ng SP.
- Pinapatunayan ng SP ang tugon at pagpapatibay. Sinusuri nito ang kinakailangang lagda, na-configure na relasyon ng tiwala, nilalayong madla at patutunguhan, panahon ng bisa, at ugnayan ng kahilingan.
- Ang SP ay lumilikha ng isang sesyon ng aplikasyon. Ang gumagamit ay ire-redirect sa hiniling na mapagkukunan, napapailalim sa mga tuntunin sa account at awtorisasyon ng aplikasyon.
Ang browser ang nagpapadala ng mga mensahe, ngunit ang desisyon sa pagtitiwala ay nasa SP. Pangkalahatang-ideya ng teknikal na OASIS SAML inilalarawan ang ugnayang ito sa pagitan ng naggigiit na IdP at umaasang SP.
Paano gumagana ang SAML SSO na sinimulan ng IdP
Sa isang daloy na sinimulan ng identity provider, nagsisimula ang user mula sa isang IdP portal o application catalog. Ipinapadala ng IdP ang browser sa SP na may hindi hinihinging tugon sa SAML; hindi muna nagpadala ang SP ng AuthnRequest.
Dahil walang orihinal na kahilingan, ang isang hindi hinihinging tugon sa pangkalahatan ay walang request identifier para maitugma ng SP sa pamamagitan ng InResponseTo. Dapat na tahasang suportahan ng SP ang IdP-initiated SSO at dapat pa ring patunayan ang lagda, issuer, audience, destination, recipient, at mga paghihigpit sa oras. Hindi nito dapat ituring ang kawalan ng request correlation bilang pahintulot na laktawan ang mga natitirang pagsusuri.
Ang pag-login na sinimulan ng SP ay nagbibigay ng mas matibay na konteksto ng kahilingan at kadalasang mas madaling iugnay sa nilalayong destinasyon ng user. Ang pag-login na sinimulan ng IdP ay maaari pa ring maging kapaki-pakinabang para sa mga portal ng application, ngunit dapat lamang itong paganahin kapag ligtas na sinusuportahan ng SP ang pattern. Ang pagkakaiba ay tinukoy sa Profile ng SSO ng SAML 2.0 Web Browser.
Paano pinapatunayan ang isang pahayag ng SAML?
Mga lagda, taga-isyu, madla, destinasyon, at mga kondisyon ng oras
Hindi sapat ang pagtanggap ng maayos na nabuo na XML. Dapat ihambing ng SP ang tugon at pahayag sa paunang na-configure na tiwala nito at sa konteksto ng pag-login.
Kabilang sa mahahalagang pagsusuri ang:
- Lagda at susi sa pagpirma: I-verify ang kinakailangang tugon o assertion signature gamit ang pinagkakatiwalaang IdP certificate. Dapat ding ipagtanggol ng implementasyon ang XML signature-wrapping at mga kaugnay na parsing attack.
- Tagapag-isyu: Kumpirmahin na tinutukoy ng assertion ang inaasahang IdP entity.
- Madla: Kumpirmahin na ang pahayag ay ibinigay para sa SP na ito, kadalasan sa pamamagitan ng paghahambing ng audience sa entity ID ng SP.
- Destinasyon at tatanggap: Kumpirmahin na ang tugon at tagapagdala ng pahayag ay naka-target sa inaasahang endpoint ng ACS.
- Mga kondisyon ng oras: Ipatupad ang mga paghihigpit sa NotBefore at NotOnOrAfter, na may kontroladong allowance lamang para sa mga pagkakaiba ng orasan.
- Humiling ng ugnayan: Para sa pag-login na sinimulan ng SP, i-verify na tumutugma ang InResponseTo sa isang natitirang kahilingan at tanggihan ang mga hindi inaasahan o paulit-ulit na tugon.
- Katayuan at pagkumpirma ng paksa: Tanggapin lamang ang isang matagumpay na tugon na ang pamamaraan ng pagkumpirma ng paksa at datos ay nakakatugon sa mga inaasahan ng SP.
Karaniwang naitatatag ang tiwala sa pamamagitan ng pagpapalitan ng SAML metadata o pag-configure ng mga katumbas na halaga sa pamamagitan ng isang protektadong prosesong administratibo. Maaaring magpadala ang metadata ng mga entity ID, endpoint, binding, at certificate, ngunit kailangan pa rin ng mga administrador ng mga pamamaraan para sa pag-validate ng mga pagbabago at pag-rotate ng mga certificate.
Dapat gumamit ng TLS ang mga SAML endpoint, at dapat gumamit ang SP ng security-reviewed XML at signature-validation implementation. Cheat Sheet ng Seguridad ng OWASP SAML nagbibigay ng gabay na nakatuon sa implementasyon para sa mga pagsusuring ito.
Ang hindi tinutukoy ng SAML authentication tungkol sa mga pahintulot ng application
Ang isang wastong pahayag ay sumasagot sa isang tanong sa pagpapatotoo: mapagkakatiwalaan ba ng SP ang pahayag ng IdP tungkol sa user na ito? Hindi nito awtomatikong pinagpapasyahan kung ano ang maaaring gawin ng user sa loob ng application.
Ang isang pahayag ay maaaring maglaman ng mga katangian ng grupo, departamento, tungkulin, o karapatan. Maaaring imapa ng SP ang mga halagang iyon sa mga lokal na tungkulin, ngunit ang sarili nitong pahintulot Tinutukoy ng patakaran kung ang isang halaga ay nagbibigay ng access. Ang parehong katangian ng grupo ay maaaring makagawa ng iba't ibang mga pahintulot sa iba't ibang mga aplikasyon.
Mahalaga rin ang estado ng account. Maaaring tanggihan ng isang SP ang isang wastong na-authenticate na user dahil ang kaukulang account ay hindi pinagana, walang lisensya, nawawala, o hindi nakatalaga sa application.
Kailan dapat gamitin ng isang organisasyon ang SAML?
Mga benepisyo at limitasyon para sa mga web application ng workforce
Malaking bagay ang SAML kapag ang isang organisasyon ay nangangailangan ng sentralisadong pagpapatotoo para sa mga web application ng enterprise na sumusuporta na sa SAML 2.0. Kabilang sa mga karaniwang halimbawa ang mga SaaS administration console at mga internal browser-based na application.
Kabilang sa mga praktikal na benepisyo nito ang:
- Nag-a-authenticate ang mga user sa pamamagitan ng IdP ng organisasyon sa halip na magpanatili ng hiwalay na password para sa bawat application.
- Maaaring maglapat ang organisasyon ng mga sentral na kontrol sa pagpapatotoo, kabilang ang mga patakaran sa multifactor authentication ng IdP.
- Ang mga aplikasyon ay maaaring makatanggap ng mga pare-parehong pagkakakilanlan ng gumagamit at mga naaprubahang katangian.
- Malawak ang suporta ng SAML sa mga matatag na enterprise web application at identity platform.
May dala ring mga gastos sa pagpapatakbo ang SAML. Komplikado ang mga mensaheng XML at pagproseso ng lagda, ang mga integrasyon ay maaaring maging sensitibo sa eksaktong mga URL at identifier, at ang mga sertipiko ng pagpirma ay nangangailangan ng pamamahala sa lifecycle. Ang disenyo nitong nakatuon sa browser ay kadalasang hindi gaanong natural para sa native mobile sign-in at awtorisasyon sa API kumpara sa mga mas bagong protocol na nakabatay sa token.
Ang tamang pagpili ay nakadepende pa rin sa kung ano ang sinusuportahan ng application. Ang pagpapalit ng isang matatag na SAML integration ng ibang protocol dahil lamang sa mas bago ito ay maaaring magbigay ng kaunting praktikal na halaga.
SAML laban sa OpenID Connect laban sa OAuth
SAML, OpenID Connect, at OAuth lutasin ang mga problemang magkakaugnay ngunit magkaiba:
| Pangangailangan | Karaniwang pagpili ng protokol | Ang ibinibigay nito |
|---|---|---|
| Enterprise browser SSO sa isang umiiral na SaaS o internal web application | SAML 2.0 | Pinagsamang pagpapatotoo sa pamamagitan ng mga XML assertion |
| Mag-sign-in para sa mga modernong web, single-page, native, o mobile application | OpenID Connect (OIDC) | Isang authentication layer na binuo sa OAuth 2.0, kabilang ang mga ID Token at mga identity claim |
| Nakatalagang access sa isang API o protektadong mapagkukunan | OAuth 2.0 | Mga token ng access na kumakatawan sa itinalagang awtorisasyon |
OpenID Connect Istandardisa ang pagpapatotoo sa ibabaw ng OAuth 2.0. Ang OAuth 2.0 ay pangunahing isang balangkas ng awtorisasyon; sa ganang sarili nito, hindi nito tinutukoy ang isang karaniwang resulta ng pagpapatotoo ng gumagamit na katumbas ng isang OIDC ID Token o SAML assertion.
Ito ay mga gabay sa arkitektura sa halip na mga ganap na tuntunin sa platform. Ang suporta sa aplikasyon, uri ng kliyente, mga kinakailangan sa seguridad, at umiiral na imprastraktura ng pagkakakilanlan ang dapat magtulak sa desisyon. Para sa mas malalim na paghahambing, tuklasin ang aming SAML laban sa OIDC at SAML laban sa OAuth gabay.
Ano ang dapat mong suriin kapag kino-configure ang SAML SSO?
Metadata ng Exchange, mga entity ID, ACS URL, at sertipiko ng paglagda
Bago paganahin ang SAML para sa mga user, maingat na paghambingin ang mga value ng configuration ng IdP at SP:
- Mga ID ng Entidad: Kumpirmahin ang eksaktong mga identifier para sa parehong IdP at SP. Ang entity ID ay isang identifier, kahit na ito ay kahawig ng isang URL; hindi ito kinakailangang isang destinasyon ng browser.
- AC URL: Ilagay ang eksaktong endpoint kung saan tinatanggap ng SP ang mga tugon ng SAML. Suriin ang mga kinakailangan sa scheme, hostname, path, port, at trailing-slash.
- URL ng SSO: I-configure ang IdP endpoint kung saan nagpapadala ang SP ng mga kahilingan sa pagpapatotoo.
- Sertipiko ng pagpirma: I-install ang tamang sertipiko ng beripikasyon ng IdP sa SP at idokumento kung paano gagana ang pag-ikot ng sertipiko.
- Mga inaasahan sa pagpirma: Tukuyin kung hinihiling ng SP na pirmahan ang tugon, pahayag, o pareho.
- Mga Pagbubuklod: Kumpirmahin ang inaasahang pagbubuklod para sa mga kahilingan at tugon, tulad ng HTTP-Redirect o HTTP-POST.
- kapaligiran: Panatilihing hiwalay ang mga test at production entity ID, ACS URL, at certificate.
- Mga halaga ng pag-logout: I-configure lamang ang Single Logout kung sinusuportahan ng parehong sistema ang nilalayong profile at session behavior.
Huwag ipagpalagay na ang pag-import ng metadata ay nag-aalis ng pangangailangang suriin ang mga halagang ito. Ang metadata ay dapat magmula sa isang napatunayang pinagmulan, at dapat maunawaan ng mga administrador kung paano pinangangasiwaan ang mga pag-update at pag-rollover ng sertipiko.
I-map ang user identifier at mga katangian, pagkatapos ay subukan ang isang login
Piliin ang identifier na gagamitin ng application upang itugma ang assertion sa isang account. Depende sa SP, maaaring ito ay isang NameID, email address, username, o stable internal identifier. Kapag sinusuportahan ito ng application, maaaring gawing mas maaasahan ng isang stable identifier ang pagtutugma ng account kaysa sa isang value tulad ng isang email address na maaaring magbago. Kumpirmahin kung paano pinangangasiwaan ng SP ang mga pagbabago sa identifier bago i-deploy.
Pagkatapos ay beripikahin:
- Ang format at value ng NameID na inaasahan ng SP
- Mga kinakailangang pangalan, format, at malaking titik ng katangian
- Mga pagmamapa ng grupo-sa-role, kung sinusuportahan ng application ang mga ito
- Kung dapat bang mayroon nang account o maaaring malikha sa tamang oras
- Kung ang IdP multifactor authentication ay gumagana ayon sa nilalayon
- Ano ang mangyayari kapag ang isang user ay hindi pinagana o hindi nakatalaga
Subukan gamit ang isang normal na user bago ipatupad ang SAML sa buong organisasyon. Panatilihin ang isang dokumentadong break-glass administrator path na hindi nakadepende sa bagong integration, kung saan sinusuportahan ito ng application. Subukan din ang rollover ng certificate at failure recovery sa halip na maghintay na mag-expire ang isang production certificate.
Paano mo i-troubleshoot ang isang nabigong SAML login?
Bago i-troubleshoot ang isang nabigong SAML login, tukuyin kung ang isyu ay nangyayari sa panahon ng IdP authentication, SAML response validation, o pag-access sa application.
Magsimula sa mga log mula sa parehong IdP at SP. Maipapakita ng IdP kung nagtagumpay ang pagpapatotoo at pag-isyu ng tugon; maipapakita rin ng SP kung bakit nito tinanggihan ang tugon o tinanggihan ang access sa aplikasyon.
| Sintomas | Mga pagsusuring isasagawa |
|---|---|
| Hindi wastong lagda o hindi mapagkakatiwalaang sertipiko | Kumpirmahin na ang SP ay mayroong tamang IdP certificate, ang inaasahang message element ay nalagdaan na, at ang certificate ay hindi nag-expire o hindi inaasahang na-rotate. |
| Nabigo ang pagpapatunay ng madla | Ihambing ang assertion audience sa SP entity ID, kabilang ang case, scheme, path, at mga trailing character. |
| Hindi pagtutugma ng destinasyon o tatanggap | Ihambing ang patutunguhan ng tugon at ang tatanggap ng paksa sa eksaktong ACS URL na tumatanggap ng mensahe. Suriin ang mga URL na test-versus-production. |
| Hindi nahanap ang user | Siyasatin ang halaga at format ng NameID. Kumpirmahin na itinutugma ito ng application sa nilalayong field ng lokal na account. |
| Kulang ang kinakailangang katangian | Suriin ang IdP attribute mapping, eksaktong pangalan ng attribute, format ng value, at kung ang test user ay may source value. |
| Nag-expire na o hindi pa balido ang asersyon | I-synchronize ang mga orasan ng system at siyasatin ang NotBefore at NotOnOrAfter. Iwasang itago ang malaking pag-agos ng oras sa pamamagitan ng pagpapahintulot ng labis na window na nagkiling sa orasan. |
| Error sa InResponseTo o kahilingan-ugnayan | Kumpirmahin na ang tugon ay tumutugma sa isang aktibong kahilingan ng SP at ang mga proxy, muling pagsubok ng browser, o mga dobleng pagsusumite ay hindi nakakagambala sa daloy. |
| Nagtagumpay ang SAML ngunit tinanggihan ang access | Suriin ang katayuan ng account, pagtatalaga ng aplikasyon, paglilisensya, at mga lokal na pagmamapa ng tungkulin o grupo. Kadalasan, ito ay isang isyu sa awtorisasyon o lifecycle ng account sa halip na nabigong pagpapatotoo. |
| Paulit-ulit na bumabalik sa IdP ang pag-login | Suriin kung matagumpay na nalilikha at napapanatili ng SP ang session cookie nito, kabilang ang cookie domain, SameSite, secure-transport, at mga paghihigpit sa browser. |
Ang mga tugon ng SAML ay maaaring maglaman ng personal na data at mga pahayag ng bearer na sensitibo ngunit wasto. Iwasan ang pag-paste ng mga kumpletong tugon sa mga hindi secure na tiket, mga tool sa chat, o mga pampublikong decoder. Kung kinakailangan ang inspeksyon ng mensahe, gumamit ng isang aprubadong proseso ng diagnostic at i-redact ang mga sensitibong halaga bago ibahagi ang mga ito.
Pasimplehin ang enterprise authentication gamit ang SAML SSO
Ang SAML ay nananatiling isang itinatag na pamantayan para sa pagpapagana ng single sign-on sa mga aplikasyon ng enterprise. Sa pamamagitan ng pagpapahintulot sa mga pinagkakatiwalaang provider ng pagkakakilanlan na patunayan ang mga gumagamit, nakakatulong ito sa mga organisasyon na isentralisa ang pagpapatotoo habang iniiwan ang mga desisyon sa pag-access na partikular sa aplikasyon sa mga indibidwal na service provider. Ang matagumpay na pagpapatupad ay nakasalalay sa wastong pag-configure ng mga relasyon sa tiwala, pagpapatunay ng mga assertion, pamamahala ng mga sertipiko, at pagsubok sa mga daloy ng pagpapatotoo. Sinusuportahan ng mga solusyon tulad ng Scalefusion OneIdP ang SAML-based SSO para sa mga compatible na aplikasyon, na tumutulong sa mga IT team na maisagawa ang mga prinsipyong ito.
galugarin Scalefusion OneIdP
Mga Madalas Itanong
1. Ano ang ibig sabihin ng SAML, at ang SAML 2.0 ba ang kasalukuyang bersyon?
Ang SAML ay nangangahulugang Security Assertion Markup Language. Ang SAML 2.0 ang kasalukuyang bersyon ng ispesipikasyon ng OASIS na ginagamit para sa mga daloy ng SSO ng browser na tinalakay sa artikulong ito, kasama ang nailathalang errata nito.
2. Gumagawa ba ang SAML SSO ng user account sa isang application?
Hindi ito nag-iisa. Pinapatunayan ng SAML ang user at maaaring magbigay ng mga katangian ng pagkakakilanlan. Maaaring mangailangan ang application ng isang dati nang account, lumikha ng isa sa pamamagitan ng just-in-time provisioning, o makatanggap ng mga account sa pamamagitan ng isang hiwalay na proseso ng provisioning.
3. Ini-encrypt ba ng pagpirma sa isang SAML assertion ang mga nilalaman nito?
Hindi. Ang lagda ay nagbibigay-daan sa SP na i-verify ang integridad at tagapirma ng assertion; hindi nito itinatago ang mga nilalaman. Ang encryption ay isang hiwalay na proteksyon na dapat i-configure at suportahan ng IdP at SP. Pinoprotektahan ng HTTPS/TLS ang transportasyon mula browser papuntang endpoint habang dinadala; hindi nito ine-encrypt ang mga nilalaman ng assertion kapag natanggap na ang mga ito o nailantad na sa isang endpoint.
4. Ang pag-sign out ba sa isang SAML application ay magsa-sign out sa iyo sa bawat aplikasyon?
Hindi naman kinakailangan. Ang pag-sign out ay karaniwang nagtatapos lamang sa sesyon ng application na iyon. Ang sesyon ng IdP at mga sesyon sa iba pang mga application ay maaaring manatiling aktibo maliban kung ang IdP at mga kalahok na SP ay sumusuporta at matagumpay na nakumpleto ang koordinadong SAML Single Logout.
