mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
162 lines
14 KiB
Markdown
162 lines
14 KiB
Markdown
{{#include ../../banners/hacktricks-training.md}}
|
|
|
|
# SAML अवलोकन
|
|
|
|
**सिक्योरिटी असेर्शन मार्कअप लैंग्वेज (SAML)** पहचान प्रदाताओं (IdP) को सेवा प्रदाताओं (SP) को प्राधिकरण क्रेडेंशियल भेजने के लिए उपयोग करने की अनुमति देता है, जिससे सिंगल साइन-ऑन (SSO) की सुविधा मिलती है। यह दृष्टिकोण कई लॉगिन के प्रबंधन को सरल बनाता है, जिससे एक ही सेट के क्रेडेंशियल को कई वेबसाइटों पर उपयोग किया जा सकता है। यह IdPs और SPs के बीच मानकीकृत संचार के लिए XML का उपयोग करता है, उपयोगकर्ता पहचान के प्रमाणीकरण को सेवा प्राधिकरण से जोड़ता है।
|
|
|
|
## SAML और OAuth के बीच तुलना
|
|
|
|
- **SAML** को उद्यमों को SSO लॉगिन सुरक्षा पर अधिक नियंत्रण प्रदान करने के लिए तैयार किया गया है।
|
|
- **OAuth** को अधिक मोबाइल-फ्रेंडली बनाने के लिए डिज़ाइन किया गया है, यह JSON का उपयोग करता है, और यह Google और Twitter जैसी कंपनियों का सहयोगात्मक प्रयास है।
|
|
|
|
# SAML प्रमाणीकरण प्रवाह
|
|
|
|
**अधिक विवरण के लिए [https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/) से पूरा पोस्ट देखें।** यह एक सारांश है:
|
|
|
|
SAML प्रमाणीकरण प्रक्रिया में कई चरण शामिल होते हैं, जैसा कि स्कीमा में दर्शाया गया है:
|
|
|
|
|
|
|
|
1. **संसाधन पहुंच प्रयास**: उपयोगकर्ता एक सुरक्षित संसाधन तक पहुंचने की कोशिश करता है।
|
|
2. **SAML अनुरोध उत्पन्न करना**: SP उपयोगकर्ता को पहचानता नहीं है और एक SAML अनुरोध उत्पन्न करता है।
|
|
3. **IdP पर पुनर्निर्देशन**: उपयोगकर्ता IdP पर पुनर्निर्देशित होता है, SAML अनुरोध उपयोगकर्ता के ब्राउज़र के माध्यम से गुजरता है।
|
|
4. **IdP अनुरोध प्राप्त करता है**: IdP SAML अनुरोध प्राप्त करता है।
|
|
5. **IdP पर प्रमाणीकरण**: IdP उपयोगकर्ता का प्रमाणीकरण करता है।
|
|
6. **उपयोगकर्ता मान्यता**: IdP उपयोगकर्ता की वैधता की पुष्टि करता है कि वह अनुरोधित संसाधन तक पहुंच सकता है।
|
|
7. **SAML प्रतिक्रिया निर्माण**: IdP आवश्यक असर्शन के साथ एक SAML प्रतिक्रिया उत्पन्न करता है।
|
|
8. **SP के ACS URL पर पुनर्निर्देशन**: उपयोगकर्ता SP के असेर्शन कंज्यूमर सर्विस (ACS) URL पर पुनर्निर्देशित होता है।
|
|
9. **SAML प्रतिक्रिया मान्यता**: ACS SAML प्रतिक्रिया की मान्यता करता है।
|
|
10. **संसाधन पहुंच दी गई**: प्रारंभ में अनुरोधित संसाधन तक पहुंच दी जाती है।
|
|
|
|
# SAML अनुरोध उदाहरण
|
|
|
|
मान लीजिए कि एक उपयोगकर्ता [https://shibdemo-sp1.test.edu/secure/](https://shibdemo-sp1.test.edu/secure/) पर एक सुरक्षित संसाधन तक पहुंच का अनुरोध करता है। SP प्रमाणीकरण की कमी को पहचानता है और एक SAML अनुरोध उत्पन्न करता है:
|
|
```
|
|
GET /secure/ HTTP/1.1
|
|
Host: shibdemo-sp1.test.edu
|
|
...
|
|
```
|
|
कच्चा SAML अनुरोध इस तरह दिखता है:
|
|
```xml
|
|
<?xml version="1.0"?>
|
|
<samlp:AuthnRequest ...
|
|
</samlp:AuthnRequest>
|
|
```
|
|
इस अनुरोध के मुख्य तत्वों में शामिल हैं:
|
|
|
|
- **AssertionConsumerServiceURL**: यह निर्दिष्ट करता है कि IdP को SAML Response को प्रमाणीकरण के बाद कहाँ भेजना चाहिए।
|
|
- **Destination**: IdP का पता जहाँ अनुरोध भेजा जाता है।
|
|
- **ProtocolBinding**: SAML प्रोटोकॉल संदेशों के संचरण विधि को परिभाषित करता है।
|
|
- **saml:Issuer**: उस इकाई की पहचान करता है जिसने अनुरोध शुरू किया।
|
|
|
|
SAML अनुरोध उत्पन्न करने के बाद, SP एक **302 रीडायरेक्ट** के साथ प्रतिक्रिया करता है, जो ब्राउज़र को SAML अनुरोध को HTTP प्रतिक्रिया के **Location** हेडर में एन्कोडेड के साथ IdP की ओर निर्देशित करता है। **RelayState** पैरामीटर लेन-देन के दौरान स्थिति जानकारी बनाए रखता है, यह सुनिश्चित करते हुए कि SP SAML Response प्राप्त करने पर प्रारंभिक संसाधन अनुरोध को पहचानता है। **SAMLRequest** पैरामीटर कच्चे XML स्निपेट का एक संकुचित और एन्कोडेड संस्करण है, जो Deflate संकुचन और base64 एन्कोडिंग का उपयोग करता है।
|
|
|
|
# SAML Response उदाहरण
|
|
|
|
आप [यहाँ पूर्ण SAML प्रतिक्रिया पा सकते हैं](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/)। प्रतिक्रिया के मुख्य घटक शामिल हैं:
|
|
|
|
- **ds:Signature**: यह अनुभाग, एक XML Signature, आश्वासन के जारीकर्ता की अखंडता और प्रामाणिकता सुनिश्चित करता है। उदाहरण में SAML प्रतिक्रिया में दो `ds:Signature` तत्व होते हैं, एक संदेश के लिए और दूसरा आश्वासन के लिए।
|
|
- **saml:Assertion**: यह भाग उपयोगकर्ता की पहचान और संभवतः अन्य विशेषताओं के बारे में जानकारी रखता है।
|
|
- **saml:Subject**: यह आश्वासन में सभी बयानों के प्रमुख विषय को निर्दिष्ट करता है।
|
|
- **saml:StatusCode**: संबंधित अनुरोध के जवाब में संचालन की स्थिति का प्रतिनिधित्व करता है।
|
|
- **saml:Conditions**: आश्वासन की वैधता समय और निर्दिष्ट सेवा प्रदाता जैसी शर्तों का विवरण देता है।
|
|
- **saml:AuthnStatement**: पुष्टि करता है कि IdP ने आश्वासन के विषय को प्रमाणित किया।
|
|
- **saml:AttributeStatement**: आश्वासन के विषय का वर्णन करने वाले विशेषताओं को शामिल करता है।
|
|
|
|
SAML Response के बाद, प्रक्रिया में IdP से 302 रीडायरेक्ट शामिल है। यह सेवा प्रदाता के आश्वासन उपभोक्ता सेवा (ACS) URL पर POST अनुरोध की ओर ले जाता है। POST अनुरोध में `RelayState` और `SAMLResponse` पैरामीटर शामिल होते हैं। ACS SAML Response को संसाधित और मान्य करने के लिए जिम्मेदार है।
|
|
|
|
POST अनुरोध प्राप्त होने और SAML Response मान्य होने के बाद, उपयोगकर्ता द्वारा प्रारंभ में अनुरोधित संरक्षित संसाधन तक पहुँच दी जाती है। यह `/secure/` एंडपॉइंट पर `GET` अनुरोध और `200 OK` प्रतिक्रिया के साथ सफल संसाधन पहुँच को दर्शाता है।
|
|
|
|
# XML Signatures
|
|
|
|
XML Signatures बहुपरकारी हैं, जो पूरे XML पेड़ या इसके भीतर विशिष्ट तत्वों पर हस्ताक्षर करने में सक्षम हैं। इन्हें किसी भी XML ऑब्जेक्ट पर लागू किया जा सकता है, केवल प्रतिक्रिया तत्वों पर नहीं। नीचे XML Signatures के मुख्य प्रकार दिए गए हैं:
|
|
|
|
### XML Signature की मूल संरचना
|
|
|
|
एक XML Signature आवश्यक तत्वों से मिलकर बनती है जैसा कि दिखाया गया है:
|
|
```xml
|
|
<Signature>
|
|
<SignedInfo>
|
|
<CanonicalizationMethod />
|
|
<SignatureMethod />
|
|
<Reference>
|
|
<Transforms />
|
|
<DigestMethod />
|
|
<DigestValue />
|
|
</Reference>
|
|
...
|
|
</SignedInfo>
|
|
<SignatureValue />
|
|
<KeyInfo />
|
|
<Object />
|
|
</Signature>
|
|
```
|
|
प्रत्येक `Reference` तत्व एक विशिष्ट संसाधन को दर्शाता है जिसे हस्ताक्षरित किया गया है, जिसे URI विशेषता द्वारा पहचाना जा सकता है।
|
|
|
|
### XML हस्ताक्षरों के प्रकार
|
|
|
|
1. **Enveloped Signature**: इस प्रकार के हस्ताक्षर उस संसाधन का वंशज होते हैं जिसे वे हस्ताक्षरित करते हैं, अर्थात् हस्ताक्षर उसी XML संरचना के भीतर होता है जैसे हस्ताक्षरित सामग्री।
|
|
|
|
उदाहरण:
|
|
|
|
```xml
|
|
<samlp:Response ... ID="..." ... >
|
|
...
|
|
<ds:Signature>
|
|
<ds:SignedInfo>
|
|
...
|
|
<ds:Reference URI="#...">
|
|
...
|
|
</ds:Reference>
|
|
</ds:SignedInfo>
|
|
</ds:Signature>
|
|
...
|
|
</samlp:Response>
|
|
```
|
|
|
|
एक enveloped हस्ताक्षर में, `ds:Transform` तत्व यह निर्दिष्ट करता है कि यह `enveloped-signature` एल्गोरिदम के माध्यम से enveloped है।
|
|
|
|
2. **Enveloping Signature**: Enveloped हस्ताक्षरों के विपरीत, enveloping हस्ताक्षर उस संसाधन को लपेटते हैं जिसे हस्ताक्षरित किया जा रहा है।
|
|
|
|
उदाहरण:
|
|
|
|
```xml
|
|
<ds:Signature>
|
|
<ds:SignedInfo>
|
|
...
|
|
<ds:Reference URI="#...">
|
|
...
|
|
</ds:Reference>
|
|
</ds:SignedInfo>
|
|
<samlp:Response ... ID="..." ... >
|
|
...
|
|
</samlp:Response>
|
|
</ds:Signature>
|
|
```
|
|
|
|
3. **Detached Signature**: यह प्रकार उस सामग्री से अलग होता है जिसे यह हस्ताक्षरित करता है। हस्ताक्षर और सामग्री स्वतंत्र रूप से मौजूद होते हैं, लेकिन दोनों के बीच एक लिंक बनाए रखा जाता है।
|
|
|
|
उदाहरण:
|
|
|
|
```xml
|
|
<samlp:Response ... ID="..." ... >
|
|
...
|
|
</samlp:Response>
|
|
<ds:Signature>
|
|
<ds:SignedInfo>
|
|
...
|
|
<ds:Reference URI="#...">
|
|
...
|
|
</ds:Reference>
|
|
</ds:SignedInfo>
|
|
</ds:Signature>
|
|
```
|
|
|
|
निष्कर्ष में, XML हस्ताक्षर XML दस्तावेज़ों को सुरक्षित करने के लिए लचीले तरीके प्रदान करते हैं, प्रत्येक प्रकार विभिन्न संरचनात्मक और सुरक्षा आवश्यकताओं की सेवा करता है।
|
|
|
|
## संदर्भ
|
|
|
|
- [https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/)
|
|
|
|
{{#include ../../banners/hacktricks-training.md}}
|