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

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

यह क्या है

क्लाइंट या अन्य सिस्टम से मिले JWT पर हस्ताक्षर की पुष्टि करता है. यह नीति दावों को कॉन्टेक्स्ट वैरिएबल में भी बांटती है, ताकि अनुमति देने या रूटिंग से जुड़े फ़ैसले लेने के लिए, बाद की नीतियों या शर्तों में उन वैल्यू की जांच की जा सके. ज़्यादा जानकारी के लिए, JWS और 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 केवीएम से हासिल किया जा सकता था), और ज़रूरी दावों और उनकी वैल्यू का सेट.

<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 में शामिल "सब" दावा, "सब्जेक्ट" एलिमेंट की ज़रूरी वैल्यू से मेल नहीं खाता, जैसा कि नीति के कॉन्फ़िगरेशन में बताया गया है.

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

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

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

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

<DisplayName>

<DisplayName>Policy Display Name</DisplayName>

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

<Algorithm>

<Algorithm>HS256</Algorithm>

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

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

<Audience>

<Audience>audience-here</Audience>

or:

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

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

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

<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/दावा>

<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>explicit-jti-value-here</Id>
 -or-
<Id ref='variable-name-here'/>
 -or-
<Id/>

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

<IgnoreCriticalHeaders>

<IgnoreCriticalHeaders>true|false</IgnoreCriticalHeaders>

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

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

<IgnoreIssuedAt>

<IgnoreIssuedAt>true|false</IgnoreIssuedAt>

जब जेडब्लयूटी में iat (जारी किया गया) दावा शामिल होने के बाद नीति में गड़बड़ी हो, तो इस नीति को 'गलत है' (डिफ़ॉल्ट) पर सेट करें. यह गड़बड़ी आने वाले समय के लिए होगी. पुष्टि करने के दौरान 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 की नीति, JWT में crit हेडर भरने के लिए, <CriticalHeaders> एलिमेंट का इस्तेमाल करती है. उदाहरण के लिए:

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

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

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

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

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

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

अगर इनबाउंड JWT में कोई ऐसा कुंजी आईडी मौजूद है जो JWKS के सेट में मौजूद है, तो नीति, JWT हस्ताक्षर की पुष्टि करने के लिए सही सार्वजनिक कुंजी का इस्तेमाल करेगी. इस सुविधा के बारे में ज़्यादा जानने के लिए, JWT की पुष्टि करने के लिए, JSON वेब कुंजी सेट (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>jwt-variable</Source>

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

<Subject>

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

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

<TimeAllowance>

<TimeAllowance>120s</TimeAllowance>

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

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

सफलता मिलने पर, JWT की पुष्टि करें और 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>