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

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

क्या

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

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

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

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

वीडियो

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

नमूने

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

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

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

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

<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 की पुष्टि करना

नीति के इस उदाहरण में, RS256 एल्गोरिदम से साइन किए गए JWT की पुष्टि की गई है. पुष्टि करने के लिए, आपको सार्वजनिक कुंजी देनी होगी. 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 में शामिल "sub" दावा, नीति कॉन्फ़िगरेशन में बताए गए "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>

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

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

ध्यान दें: कॉन्फ़िगरेशन, इस्तेमाल किए जा रहे एन्क्रिप्शन एल्गोरिदम के हिसाब से थोड़ा अलग होगा. इस्तेमाल के उदाहरणों के लिए, सैंपल देखें. इनमें खास इस्तेमाल के उदाहरणों के लिए कॉन्फ़िगरेशन दिखाए गए हैं.

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

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

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

<DisplayName>

<DisplayName>Policy Display Name</DisplayName>

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

<Algorithm>

<Algorithm>HS256</Algorithm>

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

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

<Audience>

<Audience>audience-here</Audience>

or:

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

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

<AdditionalClaims/Claim>

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

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

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

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

<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 के स्टैंडर्ड और रजिस्टर किए गए दावे के नामों में से एक नहीं है. अतिरिक्त दावे की वैल्यू, स्ट्रिंग, संख्या, बूलियन, मैप या ऐरे हो सकती है. मैप, नाम/वैल्यू के जोड़े का एक सेट होता है. इनमें से किसी भी तरह के दावे की वैल्यू, नीति के कॉन्फ़िगरेशन में साफ़ तौर पर बताई जा सकती है. इसके अलावा, फ़्लो वैरिएबल के रेफ़रंस के ज़रिए भी इसे परोक्ष तौर पर बताया जा सकता है.

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

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

<CustomClaims>

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

<Id>

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

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

<IgnoreCriticalHeaders>

<IgnoreCriticalHeaders>true|false</IgnoreCriticalHeaders>

अगर आपको यह नीति सेट करनी है कि JWT के crit हेडर में शामिल कोई भी हेडर, <KnownHeaders> एलिमेंट में शामिल न होने पर, नीति से जुड़ी गड़बड़ी दिखे, तो इसे 'गलत है' पर सेट करें. इस विकल्प को 'सही है' पर सेट करने से, VerifyJWT नीति crit हेडर को अनदेखा कर देती है.

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

<IgnoreIssuedAt>

<IgnoreIssuedAt>true|false</IgnoreIssuedAt>

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

<IgnoreUnresolvedVariables>

<IgnoreUnresolvedVariables>true|false</IgnoreUnresolvedVariables>

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

<Issuer>

<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 नीति, <CriticalHeaders> एलिमेंट का इस्तेमाल करके JWT में crit हेडर भरती है. उदाहरण के लिए:

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

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

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

<PublicKey/Certificate>

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

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

<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 Web Key Set (JWKS) का इस्तेमाल करना लेख पढ़ें.

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

<PublicKey/Value>

<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 में से कोई एक हो.

<SecretKey/Value>

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

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

<Source>

<Source>jwt-variable</Source>

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

<Subject>

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

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

<TimeAllowance>

<TimeAllowance>120s</TimeAllowance>

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

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

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

jwt.{policy_name}.{variable_name}

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

गड़बड़ी की जानकारी

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

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

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

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

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

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

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

गड़बड़ी के रिस्पॉन्स का उदाहरण

गड़बड़ी ठीक करने के लिए, सबसे सही तरीका यह है कि गड़बड़ी के 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>