JWT की नीति की पुष्टि करें

Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं.
जानकारी

यह क्या है

क्लाइंट या अन्य सिस्टम से मिले JWT पर हस्ताक्षर की पुष्टि करता है. यह नीति दावों को कॉन्टेक्स्ट वैरिएबल में भी निकालती है, ताकि बाद की नीतियां या शर्तें, अनुमति देने या रूटिंग से जुड़े फ़ैसले लेने के लिए उन वैल्यू की जांच कर सकें. ज़्यादा जानकारी के लिए, JWS और JWT की नीतियों की खास जानकारी देखें.

इस नीति को लागू करने पर, Edge किसी JWT के हस्ताक्षर की पुष्टि करता है. साथ ही, यह पुष्टि करता है कि JWT खत्म होने की तारीख के हिसाब से मान्य है और मौजूद न होने पर उस समय से पहले नहीं. इस नीति का इस्तेमाल करके, JWT पर किए गए खास दावों की वैल्यू की भी पुष्टि की जा सकती है. जैसे, विषय, जारी करने वाला, ऑडियंस या दूसरे दावों की वैल्यू.

अगर जेडब्लयूटी की पुष्टि हो चुकी है और वह मान्य है, तो जेडब्लयूटी में शामिल सभी दावों को कॉन्टेक्स्ट वैरिएबल में एक्सट्रैक्ट कर लिया जाता है, ताकि बाद की नीतियों या शर्तों के हिसाब से उनका इस्तेमाल किया जा सके. साथ ही, अनुरोध पर आगे की कार्रवाई की जा सकती है. अगर JWT हस्ताक्षर की पुष्टि नहीं की जा सकती या किसी टाइमस्टैंप की वजह से JWT अमान्य है, तो सभी प्रोसेसिंग रुक जाती है और जवाब में एक गड़बड़ी दिखती है.

JWT के हिस्सों के बारे में जानने और उन्हें एन्क्रिप्ट (सुरक्षित) और साइन करने के तरीके के बारे में जानने के लिए, RFC7519 पर जाएं.

वीडियो

JWT पर हस्ताक्षर की पुष्टि करने का तरीका जानने के लिए यह छोटा वीडियो देखें.

सैंपल

HS256 एल्गोरिदम की मदद से साइन किए गए JWT की पुष्टि करें

यह नीति, ऐसे JWT की पुष्टि करती है जिसे HS256 एन्क्रिप्शन एल्गोरिदम, एचएमएसी के साथ साइन किया गया है. इसके लिए, SHA-256 चेकसम का इस्तेमाल किया जाता है. JWT को प्रॉक्सी अनुरोध में पास किया जाता है. ऐसा करने के लिए, jwt नाम के फ़ॉर्म पैरामीटर का इस्तेमाल किया जाता है. यह कुंजी, private.secretkey नाम के वैरिएबल में होती है. पूरा उदाहरण देखने के लिए, ऊपर दिया गया वीडियो देखें. इसमें नीति के लिए अनुरोध करने का तरीका भी बताया गया है.

नीति के कॉन्फ़िगरेशन में वह जानकारी शामिल है जो Edge को JWT को डिकोड और आकलन करने के लिए चाहिए. जैसे, JWT कहां मिलेगा (सोर्स एलिमेंट में बताए गए फ़्लो वैरिएबल में), ज़रूरी साइनिंग एल्गोरिदम, सीक्रेट कुंजी को कहां खोजना है (Edge फ़्लो वैरिएबल में सेव किया गया, जो एज केवीएम से वापस लाया जा सकता हो). उदाहरण के लिए, ज़रूरी दावों और उनकी वैल्यू का सेट.

<VerifyJWT name="JWT-Verify-HS256">
    <DisplayName>JWT Verify HS256</DisplayName>
    <Algorithm>HS256</Algorithm>
    <Source>request.formparam.jwt</Source>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <SecretKey encoding="base64">
        <Value ref="private.secretkey"/>
    </SecretKey>
    <Subject>monty-pythons-flying-circus</Subject>
    <Issuer>urn://apigee-edge-JWT-policy-test</Issuer>
    <Audience>fans</Audience>
    <AdditionalClaims>
        <Claim name="show">And now for something completely different.</Claim>
    </AdditionalClaims>
</VerifyJWT>

नीति अपने आउटपुट को कॉन्टेक्स्ट वैरिएबल पर लिखती है, ताकि एपीआई प्रॉक्सी में बाद की नीतियां या शर्तें उन वैल्यू की जांच कर सकें. इस नीति के ज़रिए सेट किए गए वैरिएबल की सूची के लिए, फ़्लो वैरिएबल देखें.

RS256 एल्गोरिदम की मदद से साइन किए गए JWT की पुष्टि करें

यह नीति, उस JWT की पुष्टि करती है जिसे RS256 एल्गोरिदम की मदद से साइन किया गया था. पुष्टि करने के लिए, आपको सार्वजनिक कुंजी देनी होगी. JWT को प्रॉक्सी अनुरोध में पास किया जा सकता है. इसके लिए, jwt नाम के फ़ॉर्म पैरामीटर का इस्तेमाल किया जाता है. सार्वजनिक कुंजी, public.publickey नाम के वैरिएबल में होती है. पूरा उदाहरण देखने के लिए, ऊपर दिया गया वीडियो देखें. इसमें नीति के लिए अनुरोध करने का तरीका भी बताया गया है.

इस सैंपल नीति में, हर एलिमेंट की ज़रूरी शर्तों और विकल्पों के बारे में जानने के लिए, एलिमेंट रेफ़रंस देखें.

<VerifyJWT name="JWT-Verify-RS256">
    <Algorithm>RS256</Algorithm>
    <Source>request.formparam.jwt</Source>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <PublicKey>
        <Value ref="public.publickey"/>
    </PublicKey>
    <Subject>apigee-seattle-hatrack-montage</Subject>
    <Issuer>urn://apigee-edge-JWT-policy-test</Issuer>
    <Audience>urn://c60511c0-12a2-473c-80fd-42528eb65a6a</Audience>
    <AdditionalClaims>
        <Claim name="show">And now for something completely different.</Claim>    
    </AdditionalClaims>
</VerifyJWT>

ऊपर दिए गए कॉन्फ़िगरेशन के लिए, इस हेडर वाला JWT ...

{
  "typ" : "JWT", 
  "alg" : "RS256"
}

और यह पेलोड ...

{ 
  "sub" : "apigee-seattle-hatrack-montage",
  "iss" : "urn://apigee-edge-JWT-policy-test",
  "aud" : "urn://c60511c0-12a2-473c-80fd-42528eb65a6a",
  "show": "And now for something completely different."
}

... अगर दिए गए सार्वजनिक पासकोड से हस्ताक्षर की पुष्टि की जा सकती है, तो इसे मान्य माना जाएगा.

इसी हेडर वाला JWT, लेकिन इस पेलोड के साथ ...

{ 
  "sub" : "monty-pythons-flying-circus",
  "iss" : "urn://apigee-edge-JWT-policy-test",
  "aud" : "urn://c60511c0-12a2-473c-80fd-42528eb65a6a",
  "show": "And now for something completely different."
}

... को अमान्य माना जाएगा, भले ही हस्ताक्षर की पुष्टि की जा सकती हो. ऐसा इसलिए है, क्योंकि JWT में शामिल "सब" का दावा, "Subject" एलिमेंट की ज़रूरी वैल्यू से मेल नहीं खाता, जैसा कि नीति के कॉन्फ़िगरेशन में बताया गया है.

नीति अपने आउटपुट को कॉन्टेक्स्ट वैरिएबल पर लिखती है, ताकि एपीआई प्रॉक्सी में बाद की नीतियां या शर्तें उन वैल्यू की जांच कर सकें. इस नीति के ज़रिए सेट किए गए वैरिएबल की सूची के लिए, फ़्लो वैरिएबल देखें.

मुख्य एलिमेंट सेट करना

JWT की पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजी तय करने के लिए जिन एलिमेंट का इस्तेमाल किया जाता है वे चुने गए एल्गोरिदम पर निर्भर करते हैं. जैसा कि इस टेबल में दिखाया गया है:

एल्‍गोरि‍दम मुख्य एलिमेंट
एचएस*
<SecretKey encoding="base16|hex|base64|base64url">
  <Value ref="private.secretkey"/>
</SecretKey>
आरएस*, स्पेन*, पेन्स*
<PublicKey>
  <Value ref="rsa_public_key_or_value"/>
</PublicKey>

या:

<PublicKey>
  <Certificate ref="signed_cert_val_ref"/>
</PublicKey>

या:

<PublicKey>
  <JWKS ref="jwks_val_or_ref"/>
</PublicKey>
*ज़रूरी शर्तों के बारे में ज़्यादा जानने के लिए, सिग्नेचर एन्क्रिप्ट (सुरक्षित) करने के एल्गोरिदम के बारे में जानकारी देखें.

एलिमेंट का रेफ़रंस

नीति का रेफ़रंस, पुष्टि वाले JWT नीति के एलिमेंट और एट्रिब्यूट के बारे में बताता है.

ध्यान दें: आपके एन्क्रिप्शन के लिए इस्तेमाल किए जाने वाले एल्गोरिदम के आधार पर, कॉन्फ़िगरेशन कुछ अलग-अलग होगा. इस्तेमाल के कुछ खास उदाहरणों के कॉन्फ़िगरेशन की जानकारी देने वाले उदाहरणों के लिए, सैंपल देखें.

टॉप-लेवल एलिमेंट पर लागू होने वाले एट्रिब्यूट

<VerifyJWT name="JWT" continueOnError="false" enabled="true" async="false">

ये एट्रिब्यूट, नीति के सभी पैरंट एलिमेंट के लिए एक जैसे हैं.

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
नाम नीति का अंदरूनी नाम. नाम में इस्तेमाल किए जा सकने वाले वर्ण, इन पर पाबंदी है: A-Z0-9._\-$ %. हालांकि, Edge मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) अतिरिक्त पाबंदियां लागू करता है, जैसे कि उन वर्णों को अपने-आप हटाना जो अक्षर और अंक नहीं हैं.

इसके अलावा, मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) के प्रॉक्सी एडिटर में, नीति को आम भाषा के अलग नाम से लेबल करने के लिए, <displayname></displayname> एलिमेंट का इस्तेमाल करें.

लागू नहीं ज़रूरी है
जारी रखें पर गड़बड़ी किसी नीति के काम न करने पर गड़बड़ी दिखाने के लिए, इसे false पर सेट करें. ज़्यादातर नीतियों में ऐसा होना आम बात है.

किसी नीति के काम न करने पर भी फ़्लो एक्ज़ीक्यूट करने की प्रोसेस जारी रखने के लिए, true पर सेट करें.

गलत ज़रूरी नहीं
चालू किया गया नीति लागू करने के लिए, true पर सेट करें.

नीति को "बंद करने" के लिए, false पर सेट करें. फ़्लो से जुड़े रहने के बावजूद, नीति को लागू नहीं किया जाएगा.

सही ज़रूरी नहीं
एक साथ काम नहीं करने वाली प्रोसेस यह एट्रिब्यूट अब काम नहीं करता. गलत बहिष्कृत

<DisplayName>

<DisplayName>Policy Display Name</DisplayName>

मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) के प्रॉक्सी एडिटर में नीति को, आम भाषा के अलग नाम से लेबल करने के लिए, नाम एट्रिब्यूट के साथ-साथ इसका इस्तेमाल करें.

डिफ़ॉल्ट इस एलिमेंट को छोड़ने पर, नीति के नाम वाले एट्रिब्यूट की वैल्यू का इस्तेमाल किया जाता है.
मौजूदगी ज़रूरी नहीं
स्ट्रीम किस तरह की है String

<एल्गोरिदम>

<Algorithm>HS256</Algorithm>

यह नीति, टोकन पर हस्ताक्षर करने के लिए एन्क्रिप्ट (सुरक्षित) करने का एल्गोरिदम तय करती है. RS*/PS*/ES* एल्गोरिदम, सार्वजनिक/सीक्रेट कुंजी के जोड़े का इस्तेमाल करते हैं, जबकि एचएस* एल्गोरिदम, शेयर किए गए सीक्रेट कोड का इस्तेमाल करते हैं. सिग्नेचर एन्क्रिप्ट (सुरक्षित) करने के एल्गोरिदम के बारे में जानकारी भी देखें.

एक से ज़्यादा वैल्यू दी जा सकती हैं, जिन्हें कॉमा लगाकर अलग किया जा सकता है. उदाहरण के लिए, "HS256, HS512" या "RS256, PS256". हालांकि, HS* एल्गोरिदम को किसी दूसरे या ES* एल्गोरिदम के साथ नहीं जोड़ा जा सकता, क्योंकि इसके लिए खास तरह की कुंजी की ज़रूरत होती है. RS* और PS* एल्गोरिदम, दोनों को एक साथ शामिल किए जा सकते हैं.

डिफ़ॉल्ट लागू नहीं
मौजूदगी ज़रूरी है
स्ट्रीम किस तरह की है कॉमा लगाकर अलग की गई वैल्यू वाली स्ट्रिंग
मान्य वैल्यू HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512

<ऑडियंस>

<Audience>audience-here</Audience>

or:

<Audience ref='variable-name-here'/>

इस नीति से यह पुष्टि की जाती है कि JWT में ऑडियंस का दावा, कॉन्फ़िगरेशन में बताई गई वैल्यू से मेल खाता है या नहीं. अगर कोई मैच नहीं होता है, तो नीति गड़बड़ी दिखाती है. इस दावे से उन लोगों की पहचान हो जाती है जिनके लिए JWT बनाया गया. यह उन रजिस्टर किए गए दावों में से एक है जिनके बारे में RFC7519 में बताया गया है.

डिफ़ॉल्ट लागू नहीं
मौजूदगी ज़रूरी नहीं
स्ट्रीम किस तरह की है String
मान्य वैल्यू एक फ़्लो वैरिएबल या स्ट्रिंग, जो ऑडियंस की पहचान करती है.

<अतिरिक्त दावे/दावा>

<AdditionalClaims>
    <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'/>
 </AdditionalClaims>

or:

<AdditionalClaims ref='claim_payload'/>

यह पुष्टि करता है कि JWT पेलोड में कुछ और दावे शामिल हैं या नहीं और दावा किए गए दावे की वैल्यू मेल खाती हैं या नहीं.

एक अन्य दावे में ऐसे नाम का इस्तेमाल किया जाता है जो JWT के रजिस्टर किए गए स्टैंडर्ड दावों में से एक नहीं है. अतिरिक्त दावे की वैल्यू कोई स्ट्रिंग, संख्या, बूलियन, मैप या ऐरे हो सकती है. मैप बस नाम/वैल्यू पेयर का सेट होता है. इनमें से किसी भी तरह के दावे की वैल्यू को, साफ़ तौर पर नीति के कॉन्फ़िगरेशन में बताया जा सकता है. इसके अलावा, किसी फ़्लो वैरिएबल के रेफ़रंस से भी ऐसा किया जा सकता है.

डिफ़ॉल्ट लागू नहीं
मौजूदगी ज़रूरी नहीं
स्ट्रीम किस तरह की है स्ट्रिंग, संख्या, बूलियन या मैप
कैटगरी वैल्यू, कई तरह की कैटगरी का ऐरे है या नहीं, यह बताने के लिए true पर सेट करें. डिफ़ॉल्ट: false
मान्य वैल्यू कोई भी वैल्यू जिसका इस्तेमाल आपको अतिरिक्त दावे के लिए करना है.

<Claim> एलिमेंट में ये एट्रिब्यूट शामिल होते हैं:

  • name - (ज़रूरी है) दावे का नाम.
  • ref - (ज़रूरी नहीं) फ़्लो वैरिएबल का नाम. मौजूद होने पर, नीति इस वैरिएबल की वैल्यू का इस्तेमाल दावे के तौर पर करेगी. अगर ref एट्रिब्यूट और साफ़ तौर पर दावा की गई वैल्यू, दोनों के बारे में बताया गया है, तो साफ़ तौर पर दिखने वाली वैल्यू को डिफ़ॉल्ट माना जाता है. इसका इस्तेमाल तब किया जाता है, जब रेफ़र किए गए फ़्लो वैरिएबल की समस्या हल न हो.
  • type - (ज़रूरी नहीं) इनमें से एक: स्ट्रिंग (डिफ़ॉल्ट), संख्या, बूलियन या मैप
  • array - (ज़रूरी नहीं) यह बताने के लिए कि वैल्यू, टाइप का ऐरे है या नहीं, true पर सेट करें. डिफ़ॉल्ट: false.

जब <Claim> एलिमेंट शामिल किया जाता है, तब नीति को कॉन्फ़िगर करने पर, दावे के नाम स्टैटिक रूप से सेट हो जाते हैं. इसके अलावा, दावे के नाम बताने के लिए, JSON ऑब्जेक्ट को पास किया जा सकता है. JSON ऑब्जेक्ट, वैरिएबल के तौर पर पास होता है. इसलिए, दावे के नाम रनटाइम के दौरान तय किए जाते हैं.

उदाहरण के लिए:

<AdditionalClaims ref='json_claims'/>

जहां वैरिएबल json_claims के फ़ॉर्म में JSON ऑब्जेक्ट शामिल होता है:

{
  "sub" : "person@example.com",
  "iss" : "urn://secure-issuer@example.com",
  "non-registered-claim" : {
    "This-is-a-thing" : 817,
    "https://example.com/foobar" : { "p": 42, "q": false }
  }
}

<अतिरिक्तहेडर/दावा>

<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>

यह पुष्टि करता है कि JWT हेडर में एक से ज़्यादा दावे के नाम/वैल्यू के जोड़े हैं और दावा किए गए दावे की वैल्यू मेल खाती हैं.

अतिरिक्त दावे में, ऐसे नाम का इस्तेमाल किया जाता है जो JWT के रजिस्टर किए गए स्टैंडर्ड दावों में से एक नहीं है. अतिरिक्त दावे की वैल्यू, कोई स्ट्रिंग, संख्या, बूलियन, मैप या ऐरे हो सकती है. मैप बस नाम/वैल्यू पेयर का सेट होता है. इनमें से किसी भी तरह के दावे की वैल्यू को, साफ़ तौर पर नीति के कॉन्फ़िगरेशन में बताया जा सकता है. इसके अलावा, किसी फ़्लो वैरिएबल के रेफ़रंस से भी ऐसा किया जा सकता है.

डिफ़ॉल्ट लागू नहीं
मौजूदगी ज़रूरी नहीं
स्ट्रीम किस तरह की है

स्ट्रिंग (डिफ़ॉल्ट), संख्या, बूलियन या मैप.

अगर कोई टाइप तय नहीं किया गया है, तो टाइप, डिफ़ॉल्ट रूप से स्ट्रिंग पर सेट हो जाता है.

कैटगरी वैल्यू, कई तरह की कैटगरी का ऐरे है या नहीं, यह बताने के लिए true पर सेट करें. डिफ़ॉल्ट: false
मान्य वैल्यू कोई भी वैल्यू जिसका इस्तेमाल आपको अतिरिक्त दावे के लिए करना है.

<Claim> एलिमेंट में ये एट्रिब्यूट शामिल होते हैं:

  • name - (ज़रूरी है) दावे का नाम.
  • ref - (ज़रूरी नहीं) फ़्लो वैरिएबल का नाम. मौजूद होने पर, नीति इस वैरिएबल की वैल्यू का इस्तेमाल दावे के तौर पर करेगी. अगर ref एट्रिब्यूट और साफ़ तौर पर दावा की गई वैल्यू, दोनों के बारे में बताया गया है, तो साफ़ तौर पर दिखने वाली वैल्यू को डिफ़ॉल्ट माना जाता है. इसका इस्तेमाल तब किया जाता है, जब रेफ़र किए गए फ़्लो वैरिएबल की समस्या हल न हो.
  • type - (ज़रूरी नहीं) इनमें से एक: स्ट्रिंग (डिफ़ॉल्ट), संख्या, बूलियन या मैप
  • array - (ज़रूरी नहीं) यह बताने के लिए कि वैल्यू, टाइप का ऐरे है या नहीं, true पर सेट करें. डिफ़ॉल्ट: false.

<कस्टम दावे>

अहम जानकारी: फ़िलहाल, जब यूज़र इंटरफ़ेस (यूआई) से नई generateJWT नीति जोड़ी जाती है, तो Customclaims एलिमेंट शामिल किया जाता है. यह एलिमेंट काम नहीं करता है और इसे अनदेखा किया जाता है. इसके बजाय इस्तेमाल करने के लिए सही एलिमेंट <AdditionalClaims> है. सही एलिमेंट डालने के लिए, यूज़र इंटरफ़ेस को बाद में अपडेट किया जाएगा.

<आईडी>

<Id>explicit-jti-value-here</Id>
 -or-
<Id ref='variable-name-here'/>
 -or-
<Id/>

यह पुष्टि करता है कि JWT में कोई खास jti दावा है या नहीं. अगर टेक्स्ट वैल्यू और रेफ़रंस एट्रिब्यूट, दोनों खाली हैं, तो नीति एक रैंडम यूयूआईडी वाली जेटीआई जनरेट करेगी. JWT आईडी (jti) दावा, JWT का एक यूनीक आइडेंटिफ़ायर है. जेटीआई के बारे में ज़्यादा जानकारी के लिए, आरएफ़सी7519 देखें.

डिफ़ॉल्ट लागू नहीं
मौजूदगी ज़रूरी नहीं
स्ट्रीम किस तरह की है स्ट्रिंग या रेफ़रंस.
मान्य वैल्यू कोई स्ट्रिंग या आईडी वाले फ़्लो वैरिएबल का नाम.

<अनदेखाक्रिटिकलहेडर>

<IgnoreCriticalHeaders>true|false</IgnoreCriticalHeaders>

अगर JWT के क्रिट हेडर में मौजूद किसी हेडर को <KnownHeaders> एलिमेंट में शामिल नहीं किया जाता, तो नीति से गड़बड़ी का पता लगाने के लिए, नीति को 'गलत है' पर सेट करें. 'सही है' पर सेट करें, ताकि ConfirmJWT नीति की मदद से crit हेडर को अनदेखा किया जा सके.

इस एलिमेंट को 'सही' पर सेट करने की एक वजह यह है कि अगर आप टेस्टिंग एनवायरमेंट में हैं और अब तक हेडर के मौजूद न होने की स्थिति के लिए तैयार नहीं हैं.

डिफ़ॉल्ट गलत
मौजूदगी ज़रूरी नहीं
स्ट्रीम किस तरह की है बूलियन
मान्य वैल्यू सही या गलत

<ignoreIssuedAt>

<IgnoreIssuedAt>true|false</IgnoreIssuedAt>

अगर आपको यह नीति चाहिए कि JWT में ऐसा iat (जारी किया गया) दावा शामिल होने पर गड़बड़ी दिखे जो आने वाले समय के बारे में बताता है, तो नीति को 'गलत' (डिफ़ॉल्ट) पर सेट करें. 'सही है' पर सेट करें, ताकि पुष्टि के दौरान नीति iat को अनदेखा कर सके.

डिफ़ॉल्ट गलत
मौजूदगी ज़रूरी नहीं
स्ट्रीम किस तरह की है बूलियन
मान्य वैल्यू सही या गलत

<ignoreUnresolvedVariables>

<IgnoreUnresolvedVariables>true|false</IgnoreUnresolvedVariables>

अगर नीति में बताए गए किसी भी वैरिएबल को ठीक नहीं किया जा सकता, तो नीति के ज़रिए गड़बड़ी का पता चलने पर, 'गलत' पर सेट करें. किसी भी रिज़ॉल्व न किए जा सकने वाले वैरिएबल को खाली स्ट्रिंग (शून्य) के तौर पर ट्रीट करने के लिए, 'सही' पर सेट करें.

डिफ़ॉल्ट गलत
मौजूदगी ज़रूरी नहीं
स्ट्रीम किस तरह की है बूलियन
मान्य वैल्यू सही या गलत

<जारी करने वाला>

<Issuer ref='variable-name-here'/>
<Issuer>issuer-string-here</Issuer>

इस नीति से यह पुष्टि की जाती है कि JWT में जारी करने वाला, कॉन्फ़िगरेशन एलिमेंट में दी गई स्ट्रिंग से मेल खाता है या नहीं. ऐसा दावा जिससे JWT जारी करने वाले की पहचान की जा सकती है. यह दावों के रजिस्टर किए गए ऐसे सेट में से एक है जिसके बारे में RFC7519 में बताया गया है.

डिफ़ॉल्ट लागू नहीं
मौजूदगी ज़रूरी नहीं
स्ट्रीम किस तरह की है स्ट्रिंग या रेफ़रंस
मान्य वैल्यू कोई भी

<knownHeaders>

<KnownHeaders>a,b,c</KnownHeaders>

or:

<KnownHeaders ref=’variable_containing_headers’/>

GenerateJWT नीति, JWT में क्रिट हेडर को भरने के लिए <CriticalHeaders> एलिमेंट का इस्तेमाल करती है. उदाहरण के लिए:

{
  “typ: “...”,
  “alg” : “...”,
  “crit” : [ “a”, “b”, “c” ],
}

अगर JWT में क्रिट हेडर मौजूद है, तो इस नीति की मदद से उसकी जांच की जाती है. साथ ही, सूची में दिए गए हर हेडर के लिए यह जांच की जाती है कि <KnownHeaders> एलिमेंट में भी उस हेडर की सूची दी गई है या नहीं. <KnownHeaders> एलिमेंट में, क्रिट में दिए गए आइटम का सुपरसेट हो सकता है. सिर्फ़ यह ज़रूरी है कि क्रिट में दिए गए सभी हेडर, <KnownHeaders> एलिमेंट में शामिल हों. नीति को crit में ऐसा कोई भी हेडर मिलता है जो <KnownHeaders> में भी शामिल नहीं है. इस वजह से, VerificationJWT नीति लागू नहीं हो पाएगी.

विकल्प के तौर पर, क्रिट हेडर को अनदेखा करने के लिए, ConfirmJWT नीति को कॉन्फ़िगर किया जा सकता है. ऐसा करने के लिए, <IgnoreCriticalHeaders> एलिमेंट को true पर सेट किया जा सकता है.

डिफ़ॉल्ट लागू नहीं
मौजूदगी ज़रूरी नहीं
स्ट्रीम किस तरह की है कॉमा से अलग की गई स्ट्रिंग का ऐरे
मान्य वैल्यू कोई अरे या अरे वाले वैरिएबल का नाम.

<PublicKey/सर्टिफ़िकेट>

<PublicKey>
   <Certificate ref="signed_public.cert"/>
</PublicKey>
-or-
<PublicKey>
    <Certificate>
    -----BEGIN CERTIFICATE-----
    cert data
    -----END CERTIFICATE-----
    </Certificate>
</PublicKey>

यह, JWT पर हस्ताक्षर की पुष्टि करने के लिए इस्तेमाल किए गए हस्ताक्षर किए गए सर्टिफ़िकेट को तय करता है. हस्ताक्षर किए गए सर्टिफ़िकेट को फ़्लो वैरिएबल में पास करने के लिए, रेफ़रंस एट्रिब्यूट का इस्तेमाल करें या सीधे PEM में कोड में बदले गए सर्टिफ़िकेट के बारे में बताएं. सिर्फ़ तब इस्तेमाल करें, जब एल्गोरिदम RS256/RS384/RS512, PS256/PS384/PS512 या ES256/ES384/ES512 में से एक हो.

डिफ़ॉल्ट लागू नहीं
मौजूदगी आरएसए एल्गोरिदम से साइन किए गए जेडब्लयूटी की पुष्टि करने के लिए, आपको सर्टिफ़िकेट, जेडब्ल्यूकेएस या वैल्यू एलिमेंट का इस्तेमाल करना होगा.
स्ट्रीम किस तरह की है String
मान्य वैल्यू फ़्लो वैरिएबल या स्ट्रिंग.

<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 फ़ॉर्मैट (RFC 7517) में ऐसी वैल्यू बताता है जिसमें सार्वजनिक कुंजियों का सेट होता है. सिर्फ़ तब इस्तेमाल करें, जब एल्गोरिदम RS256/RS384/RS512, PS256/PS384/PS512 या ES256/ES384/ES512 में से एक हो.

अगर इनबाउंड JWT में एक कुंजी आईडी है, जो JWKS के सेट में मौजूद है, तो नीति में JWT हस्ताक्षर की पुष्टि करने के लिए सही सार्वजनिक कुंजी का इस्तेमाल किया जाएगा. इस सुविधा के बारे में ज़्यादा जानने के लिए, JWT की पुष्टि करने के लिए JSON वेब कुंजी सेट (JWKS) इस्तेमाल करना लेख पढ़ें.

सार्वजनिक यूआरएल से वैल्यू फ़ेच करने पर, Edge JWKS को 300 सेकंड तक कैश मेमोरी में सेव रखता है. कैश मेमोरी की समयसीमा खत्म होने पर Edge, JWKS को फिर से फ़ेच कर लेता है.

डिफ़ॉल्ट लागू नहीं
मौजूदगी आरएसए एल्गोरिदम का इस्तेमाल करके जेडब्लयूटी की पुष्टि करने के लिए, आपको सर्टिफ़िकेट, जेडब्ल्यूकेएस या वैल्यू एलिमेंट का इस्तेमाल करना होगा.
स्ट्रीम किस तरह की है String
मान्य वैल्यू फ़्लो वैरिएबल, स्ट्रिंग वैल्यू या यूआरएल.

<PublicKey/वैल्यू>

<PublicKey>
   <Value ref="public.publickeyorcert"/>
</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>

JWT पर हस्ताक्षर की पुष्टि करने के लिए इस्तेमाल किए जाने वाले सार्वजनिक कुंजी या सार्वजनिक प्रमाणपत्र के बारे में बताता है. फ़्लो वैरिएबल में कुंजी/सर्टिफ़िकेट पास करने के लिए, ref एट्रिब्यूट का इस्तेमाल करें या सीधे PEM से कोड में बदली गई कुंजी के बारे में बताएं. इसका इस्तेमाल सिर्फ़ तब करें, जब एल्गोरिदम RS256/RS384/RS512, PS256/PS384/PS512 या ES256/ES384/ES512 में से कोई एक हो.

डिफ़ॉल्ट लागू नहीं
मौजूदगी आरएसए एल्गोरिदम से साइन किए गए जेडब्लयूटी की पुष्टि करने के लिए, आपको सर्टिफ़िकेट, जेडब्ल्यूकेएस या वैल्यू एलिमेंट का इस्तेमाल करना होगा.
स्ट्रीम किस तरह की है String
मान्य वैल्यू फ़्लो वैरिएबल या स्ट्रिंग.

<SecretKey/वैल्यू>

<SecretKey encoding="base16|hex|base64|base64url">
  <Value ref="private.your-variable-name"/>
</SecretKey>

एचएमएसी एल्गोरिदम की मदद से, टोकन की पुष्टि करने या उन पर हस्ताक्षर करने के लिए इस्तेमाल की जाने वाली सीक्रेट कुंजी देता है. सिर्फ़ तब इस्तेमाल करें, जब एल्गोरिदम HS256, HS384, HS512 में से कोई एक हो..

डिफ़ॉल्ट लागू नहीं
मौजूदगी एचएमएसी एल्गोरिदम के लिए ज़रूरी है.
स्ट्रीम किस तरह की है String
मान्य वैल्यू

encoding के लिए, hex, base16, base64 या base64url मान्य वैल्यू हैं. कोड में बदलने के मान hex और base16 एक जैसे हैं.

फ़्लो वैरिएबल में कुंजी को पास करने के लिए, ref एट्रिब्यूट का इस्तेमाल करें.

ध्यान दें: अगर कोई फ़्लो वैरिएबल है, तो उसका प्रीफ़िक्स "निजी" होना ज़रूरी है. उदाहरण के लिए, private.mysecret

<सोर्स>

<Source>jwt-variable</Source>

यह मौजूद होने पर, उस फ़्लो वैरिएबल के बारे में बताया जाता है जिसमें नीति को, पुष्टि करने के लिए JWT मिलना चाहिए.

डिफ़ॉल्ट request.header.authorization (डिफ़ॉल्ट के बारे में अहम जानकारी के लिए ऊपर दिया गया नोट देखें).
मौजूदगी ज़रूरी नहीं
स्ट्रीम किस तरह की है String
मान्य वैल्यू एज फ़्लो के वैरिएबल का नाम.

<विषय>

<Subject>subject-string-here</Subject>

इस नीति से यह पुष्टि की जाती है कि JWT में मौजूद विषय, नीति के कॉन्फ़िगरेशन में बताई गई स्ट्रिंग से मेल खाता है या नहीं. यह दावा, JWT के विषय की पहचान करता है या उसके बारे में बयान देता है. यह RFC7519 में बताए गए दावों के मानक सेट में से एक है.

डिफ़ॉल्ट लागू नहीं
मौजूदगी ज़रूरी नहीं
स्ट्रीम किस तरह की है String
मान्य वैल्यू किसी विषय की खास तौर पर पहचान करने वाली कोई भी वैल्यू.

<TimeAllowance>

<TimeAllowance>120s</TimeAllowance>

समय के लिए "ग्रेस पीरियड". उदाहरण के लिए, अगर समयसीमा को 60 सेकंड के लिए कॉन्फ़िगर किया गया है, तो जिस JWT की समयसीमा खत्म हो चुकी है उसे भी समयसीमा खत्म होने के बाद 60 सेकंड के लिए मान्य माना जाएगा. पहले के समय का आकलन भी इसी तरह किया जाएगा. डिफ़ॉल्ट तौर पर 0 सेकंड होता है (ग्रेस पीरियड नहीं).

डिफ़ॉल्ट 0 सेकंड (ग्रेस पीरियड नहीं)
मौजूदगी ज़रूरी नहीं
स्ट्रीम किस तरह की है String
मान्य वैल्यू कोई वैल्यू या वैल्यू वाले फ़्लो वैरिएबल का रेफ़रंस. समयावधि के बारे में इस तरह से बताया जा सकता है:
  • s = सेकंड
  • मी = मिनट
  • h = घंटे
  • d = दिन

फ़्लो वैरिएबल

सफल होने पर, JWT की पुष्टि करें और JWT की पुष्टि करें नीतियां, इस पैटर्न के हिसाब से कॉन्टेक्स्ट वैरिएबल को सेट करती हैं:

jwt.{policy_name}.{variable_name}

उदाहरण के लिए, अगर नीति का नाम jwt-parse-token है , तो यह नीति JWT में बताए गए विषय को jwt.jwt-parse-token.decoded.claim.sub नाम के कॉन्टेक्स्ट वैरिएबल में सेव करेगी. (पुराने सिस्टम के साथ काम करने की सुविधा के लिए, यह jwt.jwt-parse-token.claim.subject में भी उपलब्ध होगा)

वैरिएबल का नाम ब्यौरा
claim.audience JWT ऑडियंस का दावा. यह वैल्यू, कोई स्ट्रिंग या स्ट्रिंग का ऐरे हो सकती है.
claim.expiry खत्म होने की तारीख/समय, जो epoch के बाद से मिलीसेकंड में दिखाया जाता है.
claim.issuedat टोकन जारी करने की तारीख, जिसे epoch के बाद से मिलीसेकंड में दिखाया जाता है.
claim.issuer JWT जारी करने वाले का दावा.
claim.notbefore अगर JWT में कोई nbf दावा शामिल है, तो इस वैरिएबल में वह वैल्यू होगी जिसे epoch के बाद के मिलीसेकंड में दिखाया जाता है.
claim.subject JWT विषय दावा.
claim.name पेलोड में नाम वाले दावे (स्टैंडर्ड या अतिरिक्त) की वैल्यू. इनमें से एक को, पेलोड में हर दावे के लिए सेट किया जाएगा.
decoded.claim.name पेलोड में नाम वाले दावे (स्टैंडर्ड या अतिरिक्त) की JSON-पार्स करने वाली वैल्यू. पेलोड में मौजूद हर दावे के लिए, एक वैरिएबल सेट किया जाता है. उदाहरण के लिए, JWT के जारी किए गए समय की जानकारी पाने के लिए, decoded.claim.iat का इस्तेमाल किया जा सकता है. यह जानकारी, epoch के बाद के सेकंड में दिखाई जाती है. हालांकि, claim.name फ़्लो वैरिएबल का भी इस्तेमाल किया जा सकता है, लेकिन किसी दावे को ऐक्सेस करने के लिए, इस वैरिएबल का इस्तेमाल करने का सुझाव दिया जाता है.
decoded.header.name पेलोड में हेडर की, JSON-पार्स करने वाली वैल्यू. पेलोड में हर हेडर के लिए एक वैरिएबल सेट किया जाता है. हालांकि, header.name फ़्लो वैरिएबल का भी इस्तेमाल किया जा सकता है, लेकिन हेडर को ऐक्सेस करने के लिए इस वैरिएबल का इस्तेमाल करने का सुझाव दिया जाता है.
expiry_formatted खत्म होने की तारीख/समय, ऐसी स्ट्रिंग के फ़ॉर्मैट में जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. उदाहरण: 28-09-2017T21:30:45.000+0000
header.algorithm JWT के लिए इस्तेमाल किया जाने वाला साइनिंग एल्गोरिदम. उदाहरण के लिए, RS256, HS384 वगैरह. ज़्यादा जानकारी के लिए, (एल्गोरिदम) हेडर पैरामीटर देखें.
header.kid कुंजी आईडी, अगर JWT जनरेट करते समय जोड़ा गया हो. JWT की पुष्टि करने के लिए, JWT की नीतियों की खास जानकारी वाले पेज पर जाएं. यहां "JSON वेब कुंजी सेट (JWKS) का इस्तेमाल करना" भी देखें. ज़्यादा जानकारी के लिए, (मुख्य आईडी) हेडर पैरामीटर देखें.
header.type JWT पर सेट किया जाएगा.
header.name नाम वाले हेडर की वैल्यू (स्टैंडर्ड या अतिरिक्त). इनमें से एक को JWT के हेडर वाले हर अतिरिक्त हेडर के लिए सेट किया जाएगा.
header-json JSON फ़ॉर्मैट में हेडर.
is_expired सही या गलत
payload-claim-names JWT के साथ काम करने वाले दावों की कैटगरी.
payload-json
JSON फ़ॉर्मैट में पेलोड.
seconds_remaining टोकन की समयसीमा खत्म होने से पहले, सेकंड की संख्या. अगर टोकन की समयसीमा खत्म हो गई है, तो यह संख्या नेगेटिव होगी.
time_remaining_formatted टोकन की समयसीमा खत्म होने से पहले का समय, ऐसे स्ट्रिंग के तौर पर फ़ॉर्मैट किया जाता है जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. उदाहरण: 00:59:59.926
valid पुष्टि किए गए JWT के मामले में, हस्ताक्षर की पुष्टि होने पर यह वैरिएबल सही होगा. साथ ही, अगर टोकन की समयसीमा खत्म होने वाली है, तो मौजूदा समय, टोकन की समयसीमा के खत्म होने से पहले की तारीख होगी. साथ ही, अगर वे टोकन मौजूद हैं, तो यह वैल्यू उनके बाद की होगी. अगर ऐसा नहीं है, तो गलत है.

DecodeJWT के मामले में, यह वैरिएबल सेट नहीं है.

गड़बड़ी का रेफ़रंस

इस सेक्शन में उन गड़बड़ी कोड और लौटाए गए गड़बड़ी के मैसेज के बारे में बताया गया है जो गड़बड़ी सेट करते हैं. ये मैसेज तब ट्रिगर होते हैं, जब इस नीति से गड़बड़ी होती है. यह जानकारी होना ज़रूरी है, ताकि यह पता लगाया जा सके कि आप गड़बड़ी ठीक करने के लिए नियम बना रहे हैं या नहीं. ज़्यादा जानने के लिए, नीति से जुड़ी गड़बड़ियों के बारे में ज़रूरी जानकारी और गड़बड़ी ठीक करना देखें.

रनटाइम से जुड़ी गड़बड़ियां

नीति के लागू होने पर ये गड़बड़ियां हो सकती हैं.

गड़बड़ी कोड एचटीटीपी कोड स्थिति कब होता है
steps.jwt.AlgorithmInTokenNotPresentInConfiguration 401 पुष्टि तब होती है, जब पुष्टि करने की नीति में कई एल्गोरिदम होते हैं.
steps.jwt.AlgorithmMismatch 401 'जेनरेट करें' नीति में तय किया गया एल्गोरिदम, पुष्टि करने की नीति में बताए गए एल्गोरिदम से मेल नहीं खाता. दिए गए एल्गोरिदम मेल खाने चाहिए.
steps.jwt.FailedToDecode 401 नीति से JWT को डिकोड नहीं किया जा सका. JWT शायद खराब है.
steps.jwt.GenerationFailed 401 नीति से JWT जनरेट नहीं हो सकी.
steps.jwt.InsufficientKeyLength 401 एचएस256 एल्गोरिदम के लिए 32 बाइट से कम और एचएस386 एल्गोरिदम के लिए 48 बाइट से कम और एचएस512 एल्गोरिदम के लिए 64 बाइट से कम.
steps.jwt.InvalidClaim 401 किसी गुम दावे या दावे के मेल न खाने या हेडर या हेडर के मेल न खाने पर.
steps.jwt.InvalidCurve 401 की के ज़रिए दिया गया कर्व एलिप्टिक कर्व एल्गोरिदम के लिए मान्य नहीं है.
steps.jwt.InvalidJsonFormat 401 हेडर या पेलोड में अमान्य JSON मिला.
steps.jwt.InvalidToken 401 यह गड़बड़ी तब दिखती है, जब JWT हस्ताक्षर की पुष्टि नहीं हो पाती.
steps.jwt.JwtAudienceMismatch 401 टोकन की पुष्टि नहीं होने की वजह से, ऑडियंस पर दावा नहीं किया जा सका.
steps.jwt.JwtIssuerMismatch 401 टोकन की पुष्टि नहीं होने की वजह से, आईडी जारी करने वाले का दावा गलत है.
steps.jwt.JwtSubjectMismatch 401 टोकन की पुष्टि होने के बाद, विषय का दावा नहीं किया जा सका.
steps.jwt.KeyIdMissing 401 पुष्टि करने की नीति में सार्वजनिक कुंजियों के सोर्स के तौर पर JWKS का इस्तेमाल किया जाता है. हालांकि, हस्ताक्षर किए गए JWT में हेडर में kid प्रॉपर्टी शामिल नहीं होती.
steps.jwt.KeyParsingFailed 401 सार्वजनिक कुंजी को दी गई कुंजी जानकारी से पार्स नहीं किया जा सका.
steps.jwt.NoAlgorithmFoundInHeader 401 यह तब होता है, जब JWT में एल्गोरिदम हेडर नहीं होता है.
steps.jwt.NoMatchingPublicKey 401 पुष्टि करने की नीति, JWKS का इस्तेमाल सार्वजनिक कुंजियों के सोर्स के तौर पर करती है. हालांकि, साइन इन किए गए JWT में kid की जानकारी JWKS में नहीं होती.
steps.jwt.SigningFailed 401 GenerateJWT में, HS384 या HS512 एल्गोरिदम के लिए कम से कम साइज़ से कम कुंजी का इस्तेमाल करके
steps.jwt.TokenExpired 401 इस नीति से, ऐसे टोकन की पुष्टि करने की कोशिश की जाती है जिसकी समयसीमा खत्म हो चुकी है.
steps.jwt.TokenNotYetValid 401 टोकन अभी तक मान्य नहीं है.
steps.jwt.UnhandledCriticalHeader 401 crit हेडर में मौजूद 'पुष्टि करें, JWT' नीति से मिला हेडर, KnownHeaders में शामिल नहीं है.
steps.jwt.UnknownException 401 कोई अज्ञात अपवाद हुआ.
steps.jwt.WrongKeyType 401 कुंजी का प्रकार गलत है. उदाहरण के लिए, अगर आपने एलिप्टिक कर्व एल्गोरिदम के लिए कोई आरएसए कुंजी तय की है या आरएसए एल्गोरिदम के लिए कर्व कुंजी तय की है.

डिप्लॉयमेंट से जुड़ी गड़बड़ियां

ये गड़बड़ियां तब हो सकती हैं, जब इस नीति वाला प्रॉक्सी डिप्लॉय किया जाता है.

गड़बड़ी का नाम वजह समाधान
InvalidNameForAdditionalClaim अगर <AdditionalClaims> एलिमेंट के चाइल्ड एलिमेंट <Claim> में इस्तेमाल किया गया दावा, इन रजिस्टर किए गए नामों में से कोई एक है, तो डिप्लॉयमेंट नहीं हो पाएगा: kid, iss, sub, aud, iat, exp, nbf या jti.
InvalidTypeForAdditionalClaim अगर <AdditionalClaims> एलिमेंट के चाइल्ड एलिमेंट <Claim> में इस्तेमाल किया गया दावा, string, number, boolean या map का टाइप नहीं है, तो डिप्लॉयमेंट नहीं हो पाएगा.
MissingNameForAdditionalClaim अगर <AdditionalClaims> एलिमेंट के चाइल्ड एलिमेंट में <Claim> के बारे में जानकारी नहीं दी गई है, तो डिप्लॉयमेंट नहीं हो पाएगा.
InvalidNameForAdditionalHeader यह गड़बड़ी तब दिखती है, जब <AdditionalClaims> एलिमेंट के चाइल्ड एलिमेंट <Claim> में इस्तेमाल किए गए दावे का नाम alg या typ होता है.
InvalidTypeForAdditionalHeader अगर <AdditionalClaims> एलिमेंट के <Claim> एलिमेंट में इस्तेमाल किए गए दावे का टाइप string, number, boolean या map टाइप का नहीं है, तो डिप्लॉयमेंट की सुविधा काम नहीं करेगी.
InvalidValueOfArrayAttribute यह गड़बड़ी तब होती है, जब चाइल्ड एलिमेंट <Claim> के <AdditionalClaims> एलिमेंट में अरे एट्रिब्यूट की वैल्यू true या false पर सेट नहीं की जाती.
InvalidValueForElement अगर <Algorithm> एलिमेंट में तय की गई वैल्यू काम नहीं करती, तो डिप्लॉयमेंट काम नहीं करेगी.
MissingConfigurationElement यह गड़बड़ी तब होती है, जब <PrivateKey> एलिमेंट को आरएसए फ़ैमिली एल्गोरिदम के साथ इस्तेमाल नहीं किया जाता है या <SecretKey> एलिमेंट को एचएस फ़ैमिली एल्गोरिदम के साथ इस्तेमाल नहीं किया जाता है.
InvalidKeyConfiguration अगर <PrivateKey> या <SecretKey> एलिमेंट में चाइल्ड एलिमेंट <Value> या इसके बारे में जानकारी नहीं दी गई है, तो डिप्लॉयमेंट नहीं हो पाएगा.
EmptyElementForKeyConfiguration <PrivateKey> या <SecretKey> एलिमेंट में शामिल चाइल्ड एलिमेंट <Value> का ref एट्रिब्यूट खाली है या नहीं तो इसे डिप्लॉय नहीं किया जा सकता.
InvalidConfigurationForVerify यह गड़बड़ी तब होती है, जब <SecretKey> एलिमेंट में <Id> एलिमेंट के बारे में बताया गया हो.
InvalidEmptyElement यह गड़बड़ी तब होती है, जब 'पुष्टि करें' JWT नीति का <Source> एलिमेंट खाली हो. अगर यह मौजूद है, तो इसे एज फ़्लो वैरिएबल के नाम से तय किया जाना चाहिए.
InvalidPublicKeyValue अगर <PublicKey> एलिमेंट के चाइल्ड एलिमेंट <JWKS> में इस्तेमाल की गई वैल्यू, आरएफ़सी 7517 में बताए गए मान्य फ़ॉर्मैट में नहीं है, तो डिप्लॉयमेंट की सुविधा काम नहीं करेगी.
InvalidConfigurationForActionAndAlgorithm अगर <PrivateKey> एलिमेंट का इस्तेमाल एचएस फ़ैमिली एल्गोरिदम के साथ किया जाता है या <SecretKey> एलिमेंट का इस्तेमाल आरएसए फ़ैमिली एल्गोरिदम के साथ किया जाता है, तो डिप्लॉयमेंट नहीं हो पाएगा.

गड़बड़ी वाले वैरिएबल

रनटाइम के दौरान गड़बड़ी होने पर ये वैरिएबल सेट होते हैं. ज़्यादा जानकारी के लिए, नीति से जुड़ी गड़बड़ियों के बारे में ज़रूरी जानकारी देखें.

वैरिएबल जगह उदाहरण
fault.name="fault_name" fault_name, गड़बड़ी का नाम है, जो ऊपर दी गई रनटाइम की गड़बड़ियां टेबल में मौजूद है. गड़बड़ी का नाम, गड़बड़ी वाले कोड का आखिरी हिस्सा होता है. fault.name Matches "TokenExpired"
JWT.failed पूरा न होने पर, सभी JWT की नीतियां एक ही वैरिएबल सेट करती हैं. JWT.failed = true

गड़बड़ी के जवाब का उदाहरण

JWT नीति के फ़ॉल्ट कोड

गड़बड़ी को ठीक करने के लिए, सबसे सही तरीका है कि आप गड़बड़ी के जवाब के errorcode हिस्से का इस्तेमाल करें. faultstring के टेक्स्ट पर भरोसा न करें, क्योंकि यह बदल सकता है.

गड़बड़ी के नियम का उदाहरण

    <FaultRules>
        <FaultRule name="JWT Policy Errors">
            <Step>
                <Name>JavaScript-1</Name>
                <Condition>(fault.name Matches "TokenExpired")</Condition>
            </Step>
            <Condition>JWT.failed=true</Condition>
        </FaultRule>
    </FaultRules>