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

आपको 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 KVM से भी वापस पाया जा सकता है.

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

नीति के इस उदाहरण में, आरएस256 एल्गोरिदम से साइन किए गए अलग किए गए JWS की पुष्टि की जाती है. पुष्टि करने के लिए, आपको सार्वजनिक कुंजी देनी होगी. JWS को प्रॉक्सी अनुरोध में, JWS नाम वाले फ़ॉर्म पैरामीटर का इस्तेमाल करके पास किया जाता है. सार्वजनिक पासकोड, public.publickey नाम के वैरिएबल में शामिल होता है.

डिटैच किए गए JWS में, JWS से पेलोड हटा दिया जाता है:

header..signature

<DetachedContent> एलिमेंट में पेलोड वाले वैरिएबल का नाम तय करके, VerifyJWS नीति को पेलोड पास करना आपकी ज़िम्मेदारी है. <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 की पुष्टि करने के लिए इस्तेमाल की गई कुंजी के बारे में बताने वाले एलिमेंट, चुने गए एल्गोरिदम पर निर्भर करते हैं. इसके बारे में यहां दी गई टेबल में बताया गया है:

<SecretKey>
  <Value ref="private.secretkey"/>
</SecretKey>

<PublicKey>
  <Value ref="rsa_public_key"/>
</PublicKey>

<PublicKey>
  <JWKS ref="jwks_val_ref_or_url"/>
</PublicKey>

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

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

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

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

<VerifyJWS name="JWS" 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* एल्गोरिदम को एक साथ इस्तेमाल किया जा सकता है.

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

यह पुष्टि करता है कि JWS हेडर में, तय किए गए अतिरिक्त दावे का नाम/वैल्यू पेयर शामिल है. साथ ही, यह भी पुष्टि करता है कि दावे की पुष्टि की गई वैल्यू मेल खाती हैं.

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

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

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

<DetachedContent>

<DetachedContent>variable-name-here</DetachedContent>

कॉन्टेंट पेलोड वाला जनरेट किया गया JWS इस फ़ॉर्म में होता है:

header.payload.signature

अगर डिटैच किए गए पेलोड को बनाने के लिए, GenerateJWS नीति का इस्तेमाल किया जाता है, तो जनरेट किए गए JWS में पेलोड शामिल नहीं होता है. साथ ही, यह इस फ़ॉर्म में होता है:

header..signature

डिटैच किए गए पेलोड के लिए, <DetachedContent> एलिमेंट का इस्तेमाल करके, पेलोड को VerifyJWS नीति पर पास करने की ज़िम्मेदारी आपकी होती है. कॉन्टेंट पेलोड को उसी ओरिजनल फ़ॉर्म में होना चाहिए जिसमें JWS हस्ताक्षर बनाते समय था.

नीति के उल्लंघन से जुड़ी गड़बड़ी तब दिखती है, जब:

• <DetachedContent> तब तय किया जाता है, जब JWS में डिटैच किया गया कॉन्टेंट पेलोड शामिल न हो (गड़बड़ी का कोड steps.jws.ContentIsNotDetached है).
• <DetachedContent> को शामिल नहीं किया गया है और JWS में अलग किया गया कॉन्टेंट पेलोड है (गड़बड़ी का कोड steps.jws.InvalidSignature है).

<IgnoreCriticalHeaders>

<IgnoreCriticalHeaders>true|false</IgnoreCriticalHeaders>

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

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

<IgnoreUnresolvedVariables>

<IgnoreUnresolvedVariables>true|false</IgnoreUnresolvedVariables>

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

<KnownHeaders>

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

or:

<KnownHeaders ref=’variable_containing_headers’/>

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

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

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

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

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

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

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

<SecretKey/Value>

<SecretKey>
  <Value ref="private.your-variable-name"/>
</SecretKey>

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

<Source>

<Source>JWS-variable</Source>

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

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

सफलता मिलने के बाद, Verify JWS और Decode JWS की नीतियां सेट की गईं इस पैटर्न के अनुसार कॉन्टेक्स्ट वैरिएबल:

jws.{policy_name}.{variable_name}

उदाहरण के लिए, अगर नीति का नाम verify-jws है, तो नीति सेव हो जाएगी इस कॉन्टेक्स्ट वैरिएबल के लिए JWS में तय एल्गोरिदम: jws.verify-jws.header.algorithm

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

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

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

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

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

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

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

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

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

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