Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं. जानकारी
यह क्या है
यह क्लाइंट या अन्य सिस्टम से मिले JWS पर हस्ताक्षर की पुष्टि करता है. यह नीति हेडर को कॉन्टेक्स्ट वैरिएबल में भी शामिल करती है, ताकि आगे की नीतियों या शर्तों में ऑथराइज़ेशन या रूटिंग से जुड़े फ़ैसले लेने के लिए, उन वैल्यू की जांच की जा सके. ज़्यादा जानकारी के लिए, JWS और JWT की नीतियों की खास जानकारी देखें.
अगर JWS की पुष्टि हो गई है और वह मान्य है, तो अनुरोध को आगे बढ़ाया जा सकता है. अगर JWS हस्ताक्षर की पुष्टि नहीं की जा सकती या अगर किसी तरह की गड़बड़ी की वजह से JWS अमान्य है, तो रिस्पॉन्स में सभी प्रोसेसिंग रुक जाती है और एक गड़बड़ी दिखती है.
JWS के हिस्सों के बारे में जानने और उन्हें एन्क्रिप्ट (सुरक्षित) और साइन करने के तरीके के बारे में जानने के लिए, RFC7515 देखें.
वीडियो
JWS पर हस्ताक्षर की पुष्टि करने का तरीका जानने के लिए, यह छोटा वीडियो देखें. इस वीडियो का मकसद, सिर्फ़ JWT की पुष्टि करना है. हालांकि, JWS के कई कॉन्सेप्ट एक जैसे ही हैं.
सैंपल
- HS256 एल्गोरिदम की मदद से साइन किए गए JWS की पुष्टि करें
- RS256 एल्गोरिदम की मदद से, अलग किए गए JWS की पुष्टि करें
HS256 एल्गोरिदम की मदद से साइन किए गए JWS की पुष्टि करें
यह उदाहरण नीति, अटैच किए गए ऐसे JWS की पुष्टि करती है जिसे HS256 एन्क्रिप्शन एल्गोरिदम, HMAC
के साथ साइन किया गया था. इस पर SHA-256 चेकसम का इस्तेमाल किया गया था. JWS को प्रॉक्सी अनुरोध में
JWS
नाम के फ़ॉर्म पैरामीटर का इस्तेमाल करके पास किया जाता है. कुंजी, private.secretkey
नाम के वैरिएबल में होती है.
अटैच किए गए JWS में, कोड में बदला गया हेडर, पेलोड, और सिग्नेचर शामिल है:
header.payload.signature
नीति के कॉन्फ़िगरेशन में वह जानकारी शामिल होती है जो Edge को JWS को डिकोड और उसका आकलन करने के लिए करना होता है.
जैसे, JWS को कहां ढूंढना (<Source>
एलिमेंट में बताए गए फ़्लो वैरिएबल में),
ज़रूरी साइनिंग एल्गोरिदम, और सीक्रेट पासकोड (Edge फ़्लो वैरिएबल में सेव किया गया, जिसे
Edge केवीएम से हासिल किया जा सकता हो) ढूंढने के लिए ज़रूरी.
<VerifyJWS name="JWS-Verify-HS256"> <DisplayName>JWS Verify HS256</DisplayName> <Algorithm>HS256</Algorithm> <Source>request.formparam.JWS</Source> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> <SecretKey> <Value ref="private.secretkey"/> </SecretKey> </VerifyJWS>
नीति अपने आउटपुट को कॉन्टेक्स्ट वैरिएबल में लिखती है, ताकि एपीआई प्रॉक्सी में बाद में आने वाली नीतियों या शर्तों में उन वैल्यू की जांच की जा सके. इस नीति के ज़रिए सेट किए गए वैरिएबल की सूची के लिए फ़्लो वैरिएबल देखें.
RS256 एल्गोरिदम की मदद से साइन किए गए अलग JWS की पुष्टि करें
यह उदाहरण नीति, अलग किए गए उस JWS की पुष्टि करती है जिसे RS256 एल्गोरिदम की मदद से साइन किया गया था. पुष्टि के लिए,
आपको सार्वजनिक कुंजी देनी होगी. JWS को प्रॉक्सी अनुरोध में पास करने के लिए, JWS
नाम के फ़ॉर्म पैरामीटर का इस्तेमाल किया जाता है. सार्वजनिक कुंजी, public.publickey
नाम के वैरिएबल में होती है.
अलग किया गया JWS, JWS से पेलोड को हटा देता है:
header..signature
<DetachedContent>
एलिमेंट को पेलोड वाले वैरिएबल का नाम तय करके,
पेलोड को VerificationJWS नीति को पास करने की ज़िम्मेदारी आपकी है. <DetachedContent>
में दिया गया कॉन्टेंट,
उस मूल रूप में होना चाहिए जिसे कोड में नहीं बदला गया है. यह उसी फ़ॉर्म में होना चाहिए जो JWS हस्ताक्षर बनाया गया था.
<VerifyJWS name="JWS-Verify-RS256"> <DisplayName>JWS Verify RS256</DisplayName> <Algorithm>RS256</Algorithm> <Source>request.formparam.JWS</Source> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> <PublicKey> <Value ref="public.publickey"/> </PublicKey> <DetachedContent>private.payload</DetachedContent> </VerifyJWS>
नीति अपने आउटपुट को कॉन्टेक्स्ट वैरिएबल में लिखती है, ताकि एपीआई प्रॉक्सी में बाद में आने वाली नीतियों या शर्तों में उन वैल्यू की जांच की जा सके. इस नीति के ज़रिए सेट किए गए वैरिएबल की सूची के लिए फ़्लो वैरिएबल देखें.
मुख्य एलिमेंट सेट करना
JWS की पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजी तय करने के लिए इस्तेमाल किए जाने वाले एलिमेंट, चुने गए एल्गोरिदम पर निर्भर करते हैं. जैसा कि इस टेबल में दिखाया गया है:
एल्गोरिदम | मुख्य एलिमेंट | |
---|---|---|
HS* |
<SecretKey> <Value ref="private.secretkey"/> </SecretKey> |
|
RS*, ES*, PS* | <PublicKey> <Value ref="rsa_public_key"/> </PublicKey> या: <PublicKey> <JWKS ref="jwks_val_ref_or_url"/> </PublicKey> |
|
*अहम शर्तों के बारे में ज़्यादा जानने के लिए, सिग्नेचर एन्क्रिप्शन एल्गोरिदम के बारे में जानकारी देखें. |
एलिमेंट का रेफ़रंस
नीति के रेफ़रंस से, पुष्टि करें JWS नीति के एलिमेंट और एट्रिब्यूट के बारे में जानकारी मिलती है.
ध्यान दें: आपके एन्क्रिप्शन एल्गोरिदम के आधार पर, कॉन्फ़िगरेशन कुछ-कुछ अलग होगा. इस्तेमाल के खास उदाहरणों से जुड़े कॉन्फ़िगरेशन की जानकारी देने वाले उदाहरण देखने के लिए, सैंपल देखें.
टॉप-लेवल एलिमेंट पर लागू होने वाले एट्रिब्यूट
<VerifyJWS name="JWS" continueOnError="false" enabled="true" async="false">
ये एट्रिब्यूट, नीति के सभी पैरंट एलिमेंट के लिए एक जैसे होते हैं.
एट्रिब्यूट | जानकारी | डिफ़ॉल्ट | मौजूदगी |
---|---|---|---|
नाम |
नीति का अंदरूनी नाम. नाम में इस्तेमाल किए जाने वाले वर्ण, इन तक सीमित हैं:
A-Z0-9._\-$ % . हालांकि, Edge मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) अतिरिक्त पाबंदियां लागू करता है. जैसे, उन वर्णों को अपने-आप हटाना जो अक्षर और अंक नहीं हैं.
इसके अलावा, मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर में नीति को आम भाषा में अलग नाम से लेबल करने के लिए, |
लागू नहीं | ज़रूरी है |
continueOnError |
इस नीति को false पर सेट करें, ताकि नीति के काम न करने पर गड़बड़ी का मैसेज दिखे. ज़्यादातर नीतियों में, ऐसा आम तौर पर किया जाता है.
किसी नीति के काम न करने पर भी फ़्लो एक्ज़ीक्यूट करने की प्रोसेस को जारी रखने के लिए, |
false | ज़रूरी नहीं |
चालू किया गया |
नीति लागू करने के लिए, true पर सेट करें.
नीति को "बंद" करने के लिए, |
सही | ज़रूरी नहीं |
async | यह एट्रिब्यूट अब काम नहीं करता. | false | बहिष्कृत |
<DisplayName>
<DisplayName>Policy Display Name</DisplayName>
मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर में नीति को एक अलग, आम भाषा के नाम से लेबल करने के लिए, नाम एट्रिब्यूट के साथ-साथ इसका इस्तेमाल करें.
डिफ़ॉल्ट | अगर इस एलिमेंट को छोड़ दिया जाता है, तो नीति के नाम वाले एट्रिब्यूट की वैल्यू का इस्तेमाल किया जाता है. |
मौजूदगी | ज़रूरी नहीं |
स्ट्रीम किस तरह की है | स्ट्रिंग |
<Algorithm>
<Algorithm>HS256</Algorithm>
टोकन पर हस्ताक्षर करने के लिए, एन्क्रिप्ट (सुरक्षित) करने का एल्गोरिदम तय करता है. RS*/PS*/ES* एल्गोरिदम, सार्वजनिक/सीक्रेट कुंजी के जोड़े का इस्तेमाल करते हैं. वहीं, एचएस* एल्गोरिदम, शेयर किए गए सीक्रेट कुंजी का इस्तेमाल करते हैं. हस्ताक्षर एन्क्रिप्ट (सुरक्षित) करने के एल्गोरिदम के बारे में जानकारी भी देखें.
एक से ज़्यादा वैल्यू को कॉमा लगाकर अलग किया जा सकता है. उदाहरण के लिए, "HS256, HS512" या "RS256, PS256". हालांकि, एचएस* एल्गोरिदम को किसी अन्य एल्गोरिदम के साथ या ES* एल्गोरिदम को किसी अन्य एल्गोरिदम के साथ नहीं जोड़ा जा सकता. ऐसा इसलिए, क्योंकि इनके लिए एक खास कुंजी टाइप की ज़रूरत होती है. RS* और PS* एल्गोरिदम, दोनों को एक साथ इस्तेमाल किए जा सकते हैं.
डिफ़ॉल्ट | लागू नहीं |
मौजूदगी | ज़रूरी है |
स्ट्रीम किस तरह की है | कॉमा लगाकर अलग की गई वैल्यू वाली स्ट्रिंग |
मान्य वैल्यू | HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512 |
<additionalHeaders/दावा>
<AdditionalHeaders> <Claim name='claim1'>explicit-value-of-claim-here</Claim> <Claim name='claim2' ref='variable-name-here'/> <Claim name='claim3' ref='variable-name-here' type='boolean'/> <Claim name='claim4' ref='variable-name' type='string' array='true'/> </AdditionalHeaders>
यह पुष्टि करता है कि JWS हेडर में बताया गया अतिरिक्त दावे का नाम/वैल्यू पेयर मौजूद है और दावा की गई दावे की वैल्यू मेल खाती हैं.
अतिरिक्त दावा ऐसे नाम का इस्तेमाल करता है जो JWS के रजिस्टर किए गए स्टैंडर्ड और रजिस्टर किए गए दावे के नामों में से एक नहीं है. किसी अतिरिक्त दावे की वैल्यू कोई स्ट्रिंग, संख्या, बूलियन, मैप या कोई अरे हो सकती है. मैप सिर्फ़ नाम/वैल्यू पेयर का सेट होता है. इनमें से किसी भी तरह के दावे की वैल्यू को, नीति के कॉन्फ़िगरेशन में साफ़ तौर पर बताया जा सकता है. इसके अलावा, किसी फ़्लो वैरिएबल के रेफ़रंस से, किसी और तरीके से इसकी वैल्यू भी तय की जा सकती है.
डिफ़ॉल्ट | लागू नहीं |
मौजूदगी | ज़रूरी नहीं |
स्ट्रीम किस तरह की है |
स्ट्रिंग (डिफ़ॉल्ट), संख्या, बूलियन या मैप. अगर कोई टाइप तय नहीं किया गया है, तो टाइप, स्ट्रिंग को डिफ़ॉल्ट रूप से सेट कर देता है. |
अरे | यह बताने के लिए कि वैल्यू, कई तरह की कैटगरी का कलेक्शन है या नहीं, true पर सेट करें. डिफ़ॉल्ट: false |
मान्य वैल्यू | कोई भी वैल्यू जिसका इस्तेमाल आपको अतिरिक्त दावे के लिए करना है. |
<Claim>
एलिमेंट में ये एट्रिब्यूट शामिल होते हैं:
- name - (ज़रूरी है) दावे का नाम.
- ref - (ज़रूरी नहीं) फ़्लो वैरिएबल का नाम. अगर यह वैल्यू मौजूद है, तो नीति इस वैरिएबल की वैल्यू को दावे के तौर पर इस्तेमाल करेगी. अगर ref एट्रिब्यूट और साफ़ तौर पर दावे की वैल्यू, दोनों के बारे में बताया गया है, तो अश्लील वैल्यू को डिफ़ॉल्ट माना जाता है. इसका इस्तेमाल तब किया जाता है, जब रेफ़र किए गए फ़्लो वैरिएबल से जुड़ी गड़बड़ी का पता नहीं चलता हो.
- type - (ज़रूरी नहीं) इनमें से कोई एक: स्ट्रिंग (डिफ़ॉल्ट), संख्या, बूलियन या मैप
- array - (ज़रूरी नहीं) यह बताने के लिए कि वैल्यू, टाइप का कलेक्शन है या नहीं, true पर सेट करें. डिफ़ॉल्ट: 'गलत'.
<DetachedContent>
<DetachedContent>variable-name-here</DetachedContent>
कॉन्टेंट पेलोड के साथ जनरेट किया गया JWS इस फ़ॉर्म में है:
header.payload.signature
अगर डिटैच किया गया पेलोड बनाने के लिए GenerateJWS नीति का इस्तेमाल किया जाता है, तो जनरेट किया गया JWS पेलोड को छोड़ देता है और इस फ़ॉर्म में होता है:
header..signature
डिटैच किए गए पेलोड के लिए, <DetachedContent>
एलिमेंट का इस्तेमाल करके, पेलोड को VerificationJWS नीति को
पास करना आपकी ज़िम्मेदारी है. दिया गया कॉन्टेंट पेलोड,
उस मूल फ़ॉर्म में होना चाहिए जिसे कोड में नहीं बदला गया था. यह उस फ़ॉर्म में होना चाहिए जब JWS हस्ताक्षर बनाया गया था.
इस नीति में गड़बड़ी तब होती है, जब:
<DetachedContent>
तब बताया जाता है, जब JWS में कोई डिटैच किया गया कॉन्टेंट पेलोड नहीं होता (गलत कोडsteps.jws.ContentIsNotDetached
है).<DetachedContent>
को हटाया गया है और JWS में अलग कॉन्टेंट पेलोड है (गलत कोडsteps.jws.InvalidSignature
है).
डिफ़ॉल्ट | N/A |
मौजूदगी | ज़रूरी नहीं |
स्ट्रीम किस तरह की है | वैरिएबल का रेफ़रंस |
<IgnoreCriticalHeaders>
<IgnoreCriticalHeaders>true|false</IgnoreCriticalHeaders>
अगर आपको यह सुविधा चाहिए कि JWS के crit हेडर में मौजूद किसी हेडर के <KnownHeaders>
एलिमेंट में शामिल न होने पर, नीति से गड़बड़ी का मैसेज मिले, तो 'गलत' पर सेट करें.
'सही है' पर सेट करें, ताकि verificationJWS नीति crit हेडर को अनदेखा कर सके.
इस एलिमेंट को 'सही' पर सेट करने की एक वजह यह है कि आप टेस्टिंग एनवायरमेंट में हैं और हेडर मौजूद न होने की वजह से नीति का उल्लंघन नहीं होना चाहिए.
डिफ़ॉल्ट | false |
मौजूदगी | ज़रूरी नहीं |
स्ट्रीम किस तरह की है | बूलियन |
मान्य वैल्यू | सही या गलत |
<IgnoreUnresolvedVariables>
<IgnoreUnresolvedVariables>true|false</IgnoreUnresolvedVariables>
अगर नीति में बताए गए किसी भी रेफ़र किए गए वैरिएबल को ठीक नहीं किया जा सकता, तो नीति से गड़बड़ी होने की सूचना मिलने पर, 'गलत' पर सेट करें. किसी भी हल न किए जा सकने वाले वैरिएबल को खाली स्ट्रिंग के तौर पर मेज़र करने के लिए, 'सही' पर सेट करें.
डिफ़ॉल्ट | false |
मौजूदगी | ज़रूरी नहीं |
स्ट्रीम किस तरह की है | बूलियन |
मान्य वैल्यू | सही या गलत |
<KnownHeaders>
<KnownHeaders>a,b,c</KnownHeaders> or: <KnownHeaders ref=’variable_containing_headers’/>
GenerateJWS नीति किसी टोकन में
crit हेडर को भरने के लिए, <CriticalHeaders>
एलिमेंट का इस्तेमाल करती है. उदाहरण के लिए:
{ “typ: “...”, “alg” : “...”, “crit” : [ “a”, “b”, “c” ], }
पुष्टि करेंJWS नीति, JWS में क्रिट हेडर के मौजूद होने पर उसकी जांच करती है. साथ ही, सूची में दिए गए हर आइटम के लिए यह जांच करती है कि <KnownHeaders>
एलिमेंट में भी उस हेडर की सूची है या नहीं. <KnownHeaders>
एलिमेंट में, crit में दिए गए आइटम का सुपरसेट हो सकता है.
सिर्फ़ यह ज़रूरी है कि crit में दिए गए सभी हेडर,
<KnownHeaders>
एलिमेंट में शामिल हों. नीति को crit में मिलने वाला ऐसा कोई भी हेडर,
जो <KnownHeaders>
में भी शामिल नहीं है, पुष्टि करने वाली JWS नीति फ़ेल हो जाती है.
विकल्प के तौर पर, <IgnoreCriticalHeaders>
एलिमेंट को true
पर सेट करके, crit हेडर को अनदेखा करने के लिए,
verificationJWS नीति को कॉन्फ़िगर किया जा सकता है.
डिफ़ॉल्ट | लागू नहीं |
मौजूदगी | ज़रूरी नहीं |
स्ट्रीम किस तरह की है | कॉमा से अलग की गई स्ट्रिंग का अरे |
मान्य वैल्यू | या तो अरे या अरे वाले वैरिएबल का नाम. |
<PublicKey/JWKS>
<!-- Specify the JWKS. --> <PublicKey> <JWKS>jwks-value-here</JWKS> </PublicKey> or: <!-- Specify a variable containing the JWKS. --> <PublicKey> <JWKS ref="public.jwks"/> </PublicKey> or: <!-- Specify a public URL that returns the JWKS. The URL is static, meaning you cannot set it using a variable. --> <PublicKey> <JWKS uri="jwks-url"/> </PublicKey>
यह JWKS फ़ॉर्मैट (आरएफ़सी 7517) में ऐसी वैल्यू बताता है जिसमें सार्वजनिक कुंजियों का सेट होता है. सिर्फ़ तब इस्तेमाल करें, जब एल्गोरिदम RS256/RS384/RS512, PS256/PS384/PS512 या ES256/ES384/ES512 में से एक हो.
अगर इनबाउंड JWS में कोई ऐसा कुंजी आईडी मौजूद है जो JWKS के सेट में मौजूद है, तो नीति, JWS हस्ताक्षर की पुष्टि करने के लिए सही सार्वजनिक कुंजी का इस्तेमाल करेगी. इस सुविधा के बारे में ज़्यादा जानकारी के लिए, JWS की पुष्टि करने के लिए JSON वेब कुंजी सेट (JWKS) का इस्तेमाल करना देखें.
अगर सार्वजनिक यूआरएल से वैल्यू फ़ेच की जाती है, तो Edge, JWKS को 300 सेकंड तक कैश मेमोरी में सेव रखता है. कैश मेमोरी की समयसीमा खत्म होने के बाद, Edge JWKS को फिर से फ़ेच कर देता है.
डिफ़ॉल्ट | लागू नहीं |
मौजूदगी | आरएसए एल्गोरिदम का इस्तेमाल करके, JWS की पुष्टि करने के लिए, आपको JWKS या वैल्यू एलिमेंट का इस्तेमाल करना होगा. |
स्ट्रीम किस तरह की है | स्ट्रिंग |
मान्य वैल्यू | फ़्लो वैरिएबल, स्ट्रिंग वैल्यू या यूआरएल. |
<PublicKey/Value>
<PublicKey> <Value ref="public.publickey"/> </PublicKey> -or- <PublicKey> <Value> -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw2kPrRzcufvUNHvTH/WW Q0UrCw5c0+Y707KX3PpXkZGbtTT4nvU1jC0d1lHV8MfUyRXmpmnNxJHAC2F73IyN C5TBtXMORc+us7A2cTtC4gZV256bT4h3sIEMsDl0Joz9K9MPzVPFxa1i0RgNt06n Xn/Bs2UbbLlKP5Q1HPxewUDEh0gVMqz9wdIGwH1pPxKvd3NltYGfPsUQovlof3l2 ALvO7i5Yrm96kknfFEWf1EjmCCKvz2vjVbBb6mp1ZpYfc9MOTZVpQcXSbzb/BWUo ZmkDb/DRW5onclGzxQITBFP3S6JXd4LNESJcTp705ec1cQ9Wp2Kl+nKrKyv1E5Xx DQIDAQAB -----END PUBLIC KEY----- </Value> </PublicKey>
यह नीति, JWS पर हस्ताक्षर की पुष्टि करने के लिए इस्तेमाल की जाने वाली सार्वजनिक कुंजी के बारे में बताती है. कुंजी को फ़्लो वैरिएबल में पास करने के लिए, ref एट्रिब्यूट का इस्तेमाल करें या सीधे PEM में कोड में बदली गई कुंजी के बारे में बताएं. एल्गोरिदम का इस्तेमाल सिर्फ़ तब करें, जब एल्गोरिदम RS256/RS384/RS512, PS256/PS384/PS512 या ES256/ES384/ES512 में से कोई एक हो.
डिफ़ॉल्ट | लागू नहीं |
मौजूदगी | आरएसए एल्गोरिदम के साथ साइन किए गए JWS की पुष्टि करने के लिए, आपको या तो JWKS या वैल्यू एलिमेंट का इस्तेमाल करना होगा. |
स्ट्रीम किस तरह की है | स्ट्रिंग |
मान्य वैल्यू | फ़्लो वैरिएबल या स्ट्रिंग. |
<SecretKey/Value>
<SecretKey> <Value ref="private.your-variable-name"/> </SecretKey>
एचएमएसी एल्गोरिदम की मदद से, टोकन की पुष्टि करने या उन पर हस्ताक्षर करने के लिए इस्तेमाल की जाने वाली सीक्रेट कुंजी देता है. इसका इस्तेमाल सिर्फ़ तब करें, जब एल्गोरिदम HS256, HS384, HS512 में से कोई एक हो. फ़्लो वैरिएबल में कुंजी पास करने के लिए, ref एट्रिब्यूट का इस्तेमाल करें.
डिफ़ॉल्ट | लागू नहीं |
मौजूदगी | एचएमएसी एल्गोरिदम के लिए ज़रूरी है. |
स्ट्रीम किस तरह की है | स्ट्रिंग |
मान्य वैल्यू |
किसी स्ट्रिंग के बारे में बताने वाला फ़्लो वैरिएबल.
ध्यान दें: अगर कोई फ़्लो वैरिएबल है, तो उसका प्रीफ़िक्स "private" होना चाहिए. उदाहरण के लिए,
|
<सोर्स>
<Source>JWS-variable</Source>
अगर यह वैल्यू मौजूद होती है, तो उस फ़्लो वैरिएबल के बारे में बताता है जिसमें नीति को पुष्टि करने के लिए, JWS को मिल सकता है.
डिफ़ॉल्ट | request.header.authorization (डिफ़ॉल्ट के बारे में अहम जानकारी पाने के लिए,
ऊपर दिया गया नोट देखें). |
मौजूदगी | ज़रूरी नहीं |
स्ट्रीम किस तरह की है | स्ट्रिंग |
मान्य वैल्यू | Edge फ़्लो वैरिएबल का नाम. |
फ़्लो वैरिएबल
सफलता मिलने पर, JWS की पुष्टि करें और JWS को डिकोड करें नीतियां, इस पैटर्न के मुताबिक कॉन्टेक्स्ट वैरिएबल को सेट करती हैं:
jws.{policy_name}.{variable_name}
उदाहरण के लिए, अगर नीति का नाम verify-jws
है, तो नीति, JWS में बताए गए एल्गोरिदम को इस कॉन्टेक्स्ट वैरिएबल के लिए सेव करेगी: jws.verify-jws.header.algorithm
वैरिएबल का नाम | ब्यौरा |
---|---|
decoded.header.name |
पेलोड में मौजूद हेडर की JSON-पार्स हो सकने वाली वैल्यू. पेलोड में हर हेडर के लिए,
एक वैरिएबल सेट किया जाता है. हालांकि, header.name फ़्लो वैरिएबल का इस्तेमाल भी किया जा सकता है, लेकिन हेडर को ऐक्सेस करने के लिए, इस वैरिएबल का इस्तेमाल करने का सुझाव दिया जाता है. |
header.algorithm |
JWS पर साइन इन करने के लिए इस्तेमाल किया जाने वाला एल्गोरिदम. उदाहरण के लिए, RS256, HS384 वगैरह. ज़्यादा जानकारी के लिए, (एल्गोरिदम) हेडर पैरामीटर देखें. |
header.kid |
कुंजी आईडी, अगर JWS जनरेट करते समय जोड़ा गया था. JWS की पुष्टि करने के लिए, JWT और JWS की नीतियों की खास जानकारी पर जाकर, "JSON वेब पासकोड सेट (JWKS)" इस्तेमाल करें. ज़्यादा जानकारी के लिए (कुंजी आईडी) हेडर पैरामीटर देखें. |
header.type |
हेडर टाइप की वैल्यू. ज़्यादा जानकारी के लिए (टाइप) हेडर पैरामीटर देखें. |
header.name |
नाम वाले हेडर की वैल्यू (स्टैंडर्ड या अतिरिक्त). इनमें से एक वैल्यू को JWS के हेडर वाले हर अतिरिक्त हेडर के लिए सेट किया जाएगा. |
header-json |
JSON फ़ॉर्मैट में हेडर. |
payload |
अगर JWS में अटैच किया गया पेलोड है, तो JWS पेलोड. डिटैच किए गए पेलोड के लिए, यह वैरिएबल खाली है. |
valid |
VerificationJWS के मामले में, सिग्नेचर की पुष्टि होने पर यह वैरिएबल 'सही' होगा. साथ ही, अगर मौजूदा समय टोकन की समयसीमा खत्म होने से पहले का होगा, तो मौजूदा समय, तब सही होगा, जब टोकन की वैल्यू पहले मौजूद हो. नहीं तो गलत है.
DecodeJWS के मामले में, यह वैरिएबल सेट नहीं है. |
गड़बड़ी का रेफ़रंस
यह सेक्शन गड़बड़ी के कोड और दिखाए गए गड़बड़ी के मैसेज के बारे में बताता है. साथ ही, इस नीति के ट्रिगर होने पर Edge की मदद से सेट की गई गड़बड़ी के वैरिएबल के बारे में बताता है. यह जानकारी जानना ज़रूरी है कि क्या गड़बड़ियों को ठीक करने के लिए, गड़बड़ी से जुड़े नियम बनाए जा रहे हैं. ज़्यादा जानने के लिए, नीति से जुड़ी गड़बड़ियों के बारे में आपके लिए ज़रूरी जानकारी और गड़बड़ियों को ठीक करने के तरीके देखें.
रनटाइम से जुड़ी गड़बड़ियां
नीति के लागू होने पर ये गड़बड़ियां हो सकती हैं.
गड़बड़ी का कोड | एचटीटीपी कोड स्थिति | कब होता है |
---|---|---|
steps.jws.AlgorithmInTokenNotPresentInConfiguration |
401 | ऐसा तब होता है जब पुष्टि करने की नीति में एक से ज़्यादा एल्गोरिदम हों |
steps.jws.AlgorithmMismatch |
401 | जनरेट करने की नीति के ज़रिए हेडर में बताए गए एल्गोरिदम, पुष्टि करें नीति में मौजूद एल्गोरिदम से मेल नहीं खाते. तय किए गए एल्गोरिदम मेल खाने चाहिए. |
steps.jws.ContentIsNotDetached |
401 | <DetachedContent> तब बताया जाता है, जब JWS में
डिटैच किया गया कॉन्टेंट पेलोड नहीं होता. |
steps.jws.FailedToDecode |
401 | यह नीति, JWS को डिकोड नहीं कर सकी. शायद JWS में कोई गड़बड़ी है. |
steps.jws.InsufficientKeyLength |
401 | HS256 एल्गोरिदम के लिए, 32 बाइट से कम की कुंजी के लिए |
steps.jws.InvalidClaim |
401 | ऐसा दावा जो मौजूद नहीं है या दावे से मेल नहीं खाता, या हेडर या हेडर मेल नहीं खाता. |
steps.jws.InvalidCurve |
401 | कुंजी से तय किया गया कर्व, एलिप्टिक कर्व एल्गोरिदम के लिए मान्य नहीं है. |
steps.jws.InvalidJsonFormat |
401 | JWS हेडर में अमान्य JSON मिला. |
steps.jws.InvalidJws |
401 | यह गड़बड़ी तब होती है, जब JWS हस्ताक्षर की पुष्टि नहीं हो पाती. |
steps.jws.InvalidPayload |
401 | JWS पेलोड अमान्य है. |
steps.jws.InvalidSignature |
401 | <DetachedContent> को हटाया गया है और JWS में अलग कॉन्टेंट पेलोड है. |
steps.jws.KeyIdMissing |
401 | पुष्टि करने की नीति के तहत, सार्वजनिक कुंजियों के लिए सोर्स के तौर पर JWKS का इस्तेमाल किया जाता है. हालांकि, साइन की गई JWS नीति के हेडर में
kid प्रॉपर्टी शामिल नहीं होती. |
steps.jws.KeyParsingFailed |
401 | सार्वजनिक कुंजी को दी गई कुंजी से पार्स नहीं किया जा सका. |
steps.jws.MissingPayload |
401 | JWS पेलोड मौजूद नहीं है. |
steps.jws.NoAlgorithmFoundInHeader |
401 | ऐसा तब होता है, जब JWS इस एल्गोरिदम हेडर को छोड़ देता है. |
steps.jws.NoMatchingPublicKey |
401 | पुष्टि करने की नीति, सार्वजनिक कुंजियों के लिए सोर्स के तौर पर JWKS का इस्तेमाल करती है. हालांकि, साइन किए गए JWS में
kid , JWKS में शामिल नहीं है. |
steps.jws.UnhandledCriticalHeader |
401 | crit हेडर में, पुष्टि करें JWS नीति से मिला हेडर,
KnownHeaders की सूची में नहीं है. |
steps.jws.UnknownException |
401 | एक अज्ञात अपवाद हुआ. |
steps.jws.WrongKeyType |
401 | कुंजी का गलत प्रकार बताया गया. उदाहरण के लिए, अगर आपने एलिप्टिक कर्व एल्गोरिदम के लिए आरएसए कुंजी या आरएसए एल्गोरिदम के लिए कोई कर्व कुंजी तय की है. |
डिप्लॉयमेंट से जुड़ी गड़बड़ियां
ये गड़बड़ियां तब हो सकती हैं, जब इस नीति वाले किसी प्रॉक्सी को डिप्लॉय किया जाता है.
गड़बड़ी का नाम | कब होता है |
---|---|
InvalidAlgorithm |
सिर्फ़ ये वैल्यू मान्य हैं: RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512, HS256, HS384, HS512. |
|
डिप्लॉयमेंट की दूसरी संभावित गड़बड़ियां. |
गड़बड़ी वाले वैरिएबल
रनटाइम में कोई गड़बड़ी होने पर ये वैरिएबल सेट किए जाते हैं. ज़्यादा जानकारी के लिए, नीति से जुड़ी गड़बड़ियों के बारे में आपके लिए ज़रूरी जानकारी देखें.
वैरिएबल | जगह | उदाहरण |
---|---|---|
fault.name="fault_name" |
fault_name, गड़बड़ी का नाम है, जैसा कि ऊपर रनटाइम की गड़बड़ियां टेबल में दिया गया है. गड़बड़ी का नाम, गड़बड़ी के कोड का आखिरी हिस्सा होता है. | fault.name Matches "TokenExpired" |
JWS.failed |
सफल न होने पर, JWS नीतियां एक ही वैरिएबल सेट करती हैं. | jws.JWS-Policy.failed = true |
गड़बड़ी के जवाब का उदाहरण
गड़बड़ी को ठीक करने के लिए, सबसे सही तरीका यह है कि आप गड़बड़ी के रिस्पॉन्स के errorcode
वाले हिस्से को
फंसा दें. faultstring
के टेक्स्ट पर भरोसा न करें, क्योंकि यह बदल सकता है.
गड़बड़ी के नियम का उदाहरण
<FaultRules> <FaultRule name="JWS Policy Errors"> <Step> <Name>JavaScript-1</Name> <Condition>(fault.name Matches "TokenExpired")</Condition> </Step> <Condition>JWS.failed=true</Condition> </FaultRule> </FaultRules>