SAML: खराब डिज़ाइन का एक फ्रैक्टल
SAML, जो enterprises में व्यापक रूप से इस्तेमाल होने वाला XML-आधारित single sign-on मानक है, को अब अधिक जटिल, असुरक्षित, और design-by-committee का ऐसा उत्पाद माना जा रहा है जिसे सही ढंग से लागू करना कठिन है। टिप्पणीकार इसे OAuth2/OpenID Connect और JWT से तुलना करते हैं, जिन्हें सरल और अधिक सुरक्षित माना जाता है, हालांकि वे भी पूरी तरह त्रुटिहीन नहीं हैं और अपने ecosystem तथा “SSO tax” जैसे व्यावसायिक प्रोत्साहनों से बोझिल हैं। कई लोगों का तर्क है कि SAML enterprise inertia और legacy IdPs के कारण बना हुआ है, लेकिन नए उत्पादों को जहाँ संभव हो OIDC को प्राथमिकता देनी चाहिए और SAML को चरणबद्ध रूप से हटाई जाने वाली legacy तकनीक मानना चाहिए.
एंटरप्राइज़ मांग बनाम विक्रेता का चयन
- कई लोगों का तर्क है कि एंटरप्राइज़ उत्पादों को वह SSO समर्थन करना चाहिए जो उनके ग्राहक इस्तेमाल करते हैं (अक्सर SAML); अन्यथा वे बस व्यवहार्य नहीं हैं।
- दूसरे जवाब देते हैं कि विक्रेताओं पर उन प्रोटोकॉल को अपनाने की बाध्यता नहीं है जिन्हें वे असुरक्षित मानते हैं; ऐसे ग्राहकों को खोना एक व्यावसायिक निर्णय है, बाध्यता नहीं।
- कुछ विक्रेता बताते हैं कि वे OIDC‑only हो गए और व्यवहार में ज़्यादातर “SAML ग्राहक” स्विच करने में ठीक थे क्योंकि उनके IdPs पहले से OIDC का समर्थन करते थे।
- आर्थिक पहलू: SAML सुविधाएँ अक्सर पेवॉल के पीछे होती हैं (“SSO tax”), और विक्रेता “स्विच ऑन” करने के लिए हज़ारों शुल्क लेते हैं, जिसे सपोर्ट और रखरखाव लागत से उचित ठहराया जाता है।
SAML बनाम OIDC/OAuth2/JWT
- व्यापक सहमति है कि SAML, OAuth2/OIDC और JWT की तुलना में अधिक जटिल और नाज़ुक है, हालांकि OAuth2/OIDC/JWT में भी गैर‑trivial pitfalls हैं।
- इस पर बहस कि “OAuth2 is shite” क्या प्रमाणीकरण के बजाय प्राधिकरण के रूप में उसके दुरुपयोग से आता है; OIDC को उचित authN परत के रूप में प्रस्तुत किया जाता है।
- कुछ का दावा है कि SAML संभवतः उद्यमी जड़ता के कारण OIDC से अधिक समय तक जीवित रहेगा; अन्य इसे IE6 जैसी अप्रचलित विरासत मानकर चरणबद्ध तरीके से हटाने की वकालत करते हैं।
सुरक्षा और कार्यान्वयन की खामियाँ
- SAML के XML signatures चर्चा का बड़ा केंद्र हैं: signatures हमलावर‑चुने गए उपसमुच्चयों को कवर कर सकते हैं, canonicalization पर निर्भर होते हैं, और XML Signature Wrapping के प्रति संवेदनशील हैं।
- कई implementations ने ऐतिहासिक रूप से एक signature को मान्य किया, फिर पूरे document पर भरोसा किया, या XML‑sig libraries का गलत उपयोग किया (जैसे attacker‑provided keys के साथ HMAC, WebPKI validation)।
- JWT/JOSE समस्याओं पर चर्चा:
alg:none, algorithm confusion, symmetric और asymmetric keys को मिलाना। फिर भी, कई प्रतिभागी JWT की समस्याओं को SAML की तुलना में कम और कम करना आसान मानते हैं।
IdP‑initiated बनाम SP‑initiated flows
- कुछ लोग IdP‑initiated SSO और “payload में baked‑in security” के लिए SAML का बचाव करते हैं, खासकर एंटरप्राइज़ portal scenarios में।
- अन्य बताते हैं कि IdP‑initiated flows login CSRF के प्रति संवेदनशील हैं; OIDC जानबूझकर उनसे बचता है, और इसके बजाय third‑party‑initiated flows का उपयोग करता है जो फिर भी SP से शुरू होते हैं।
- इस पर असहमति है कि क्या user confirmation prompts ऐसे attacks को प्रभावी रूप से कम करते हैं।
XML, जटिलता, और design‑by‑committee
- कई टिप्पणियाँ SAML की समस्याओं के लिए XML और design‑by‑committee को दोष देती हैं: signing/encryption के लिए बहुत सारे options और spec का अत्यधिक आकार।
- OSI बनाम IP, OpenVPN बनाम WireGuard, और XML बनाम JSON जैसी तुलना दी जाती है, जिनमें सरल, opinionated डिज़ाइन बेहतर माने जाते हैं।
Federated identity, “SSO tax,” और alternatives
- Original OpenID, OpenID Connect dynamic discovery/registration, IndieAuth, और DID/FedCM को provider‑independent identity के building blocks के रूप में उद्धृत किया जाता है।
- थ्रेड की सहमति: व्यापक federated login को तकनीक की कमी नहीं, बल्कि business incentives (data hoarding, SSO upsell) रोकते हैं।
- कुछ सुझाव देते हैं कि व्यवहार में अब SCIM की असंगतियाँ SAML बनाम OIDC protocol प्रश्नों की तुलना में अधिक प्रयास लेती हैं।