سیاست JWT را تأیید کنید

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

چه

امضای JWT دریافتی از کلاینت‌ها یا سایر سیستم‌ها را تأیید می‌کند. این خط‌مشی همچنین ادعاها را در متغیرهای زمینه‌ای استخراج می‌کند تا خط‌مشی‌ها یا شرایط بعدی بتوانند آن مقادیر را برای تصمیم‌گیری در مورد مجوز یا مسیریابی بررسی کنند. برای مقدمه‌ای مفصل ، به نمای کلی خط‌مشی‌های JWS و JWT مراجعه کنید.

وقتی این سیاست اجرا می‌شود، Edge امضای یک JWT را تأیید می‌کند و اعتبار JWT را بر اساس زمان‌های انقضا و عدم وجود آنها در صورت وجود، تأیید می‌کند. این سیاست می‌تواند به صورت اختیاری مقادیر ادعاهای خاص در JWT، مانند موضوع، صادرکننده، مخاطب یا ارزش ادعاهای اضافی را نیز تأیید کند.

اگر JWT تأیید و معتبر باشد، تمام ادعاهای موجود در JWT برای استفاده توسط سیاست‌ها یا شرایط بعدی به متغیرهای زمینه‌ای استخراج می‌شوند و درخواست اجازه ادامه پیدا می‌کند. اگر امضای JWT قابل تأیید نباشد یا اگر JWT به دلیل یکی از مهرهای زمانی نامعتبر باشد، تمام پردازش متوقف می‌شود و خطایی در پاسخ برگردانده می‌شود.

برای کسب اطلاعات در مورد اجزای یک JWT و نحوه رمزگذاری و امضای آنها، به RFC7519 مراجعه کنید.

ویدئو

برای یادگیری نحوه تأیید امضا در JWT، یک ویدیوی کوتاه تماشا کنید.

نمونه‌ها

• تأیید یک JWT امضا شده با الگوریتم HS256
• تأیید یک JWT امضا شده با الگوریتم RS256

تأیید یک JWT امضا شده با الگوریتم HS256

این سیاست نمونه، یک JWT را که با الگوریتم رمزگذاری HS256، HMAC با استفاده از SHA-256 checksum امضا شده است، تأیید می‌کند. JWT با استفاده از یک پارامتر فرم به نام jwt در درخواست پروکسی ارسال می‌شود. کلید در متغیری به نام private.secretkey قرار دارد. برای مثال کامل، از جمله نحوه ارسال درخواست به این سیاست، به ویدیوی بالا مراجعه کنید.

پیکربندی سیاست شامل اطلاعاتی است که Edge برای رمزگشایی و ارزیابی JWT نیاز دارد، مانند محل یافتن JWT (در یک متغیر جریان مشخص شده در عنصر Source)، الگوریتم امضای مورد نیاز، محل یافتن کلید مخفی (ذخیره شده در یک متغیر جریان 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>

این خط‌مشی خروجی خود را در متغیرهای زمینه می‌نویسد تا خط‌مشی‌ها یا شرایط بعدی در پروکسی API بتوانند آن مقادیر را بررسی کنند. برای فهرستی از متغیرهای تنظیم‌شده توسط این خط‌مشی، به متغیرهای جریان مراجعه کنید.

تأیید یک JWT امضا شده با الگوریتم RS256

این سیاست نمونه، یک 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 با همان هدر اما با این payload ...

{ 
  "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."
}

... نامعتبر تشخیص داده خواهد شد، حتی اگر امضا قابل تأیید باشد، زیرا ادعای "sub" موجود در JWT با مقدار مورد نیاز عنصر "Subject" که در پیکربندی خط‌مشی مشخص شده است، مطابقت ندارد.

این خط‌مشی خروجی خود را در متغیرهای زمینه می‌نویسد تا خط‌مشی‌ها یا شرایط بعدی در پروکسی API بتوانند آن مقادیر را بررسی کنند. برای فهرستی از متغیرهای تنظیم‌شده توسط این خط‌مشی، به متغیرهای جریان مراجعه کنید.

تنظیم عناصر کلیدی

عناصری که برای مشخص کردن کلید مورد استفاده برای تأیید 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>Policy Display Name</DisplayName>

علاوه بر ویژگی نام، از این ویژگی برای برچسب‌گذاری سیاست در ویرایشگر پروکسی رابط کاربری مدیریت با یک نام متفاوت به زبان طبیعی استفاده کنید.

<الگوریتم>

<Algorithm>HS256</Algorithm>

الگوریتم رمزگذاری برای امضای توکن را مشخص می‌کند. الگوریتم‌های RS*/PS*/ES* از یک جفت کلید عمومی/مخفی استفاده می‌کنند، در حالی که الگوریتم‌های HS* از یک کلید مخفی مشترک استفاده می‌کنند. همچنین به «درباره الگوریتم‌های رمزگذاری امضا» مراجعه کنید.

شما می‌توانید چندین مقدار را که با کاما از هم جدا شده‌اند، مشخص کنید. برای مثال "HS256، HS512" یا "RS256، PS256". با این حال، نمی‌توانید الگوریتم‌های HS* را با هیچ الگوریتم دیگری یا الگوریتم‌های ES* را با هیچ الگوریتم دیگری ترکیب کنید زیرا به یک نوع کلید خاص نیاز دارند. می‌توانید الگوریتم‌های RS* و PS* را با هم ترکیب کنید.

<مخاطب>

<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 payload شامل claim(s) اضافی مشخص شده است و مقادیر claim ادعا شده مطابقت دارند.

یک ادعای اضافی از نامی استفاده می‌کند که جزو نام‌های ادعای استاندارد و ثبت‌شده‌ی JWT نیست. مقدار یک ادعای اضافی می‌تواند یک رشته، عدد، مقدار بولی، نگاشت یا آرایه باشد. یک نگاشت صرفاً مجموعه‌ای از جفت‌های نام/مقدار است. مقدار هر یک از این نوع ادعاها را می‌توان به صراحت در پیکربندی سیاست یا به طور غیرمستقیم از طریق ارجاع به یک متغیر جریان مشخص کرد.

عنصر <Claim> این ویژگی‌ها را می‌پذیرد:

• نام - (الزامی) نام ادعا.
• ref - (اختیاری) نام یک متغیر جریان. در صورت وجود، سیاست از مقدار این متغیر به عنوان ادعا استفاده خواهد کرد. اگر هم ویژگی ref و هم مقدار ادعای صریح مشخص شده باشند، مقدار صریح پیش‌فرض است و در صورتی استفاده می‌شود که متغیر جریان ارجاع داده شده حل نشده باشد.
• نوع - (اختیاری) یکی از: رشته (پیش‌فرض)، عدد، بولی یا نقشه
• آرایه - (اختیاری) برای نشان دادن اینکه آیا مقدار، آرایه‌ای از انواع است یا خیر، روی 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 نیست. مقدار یک ادعای اضافی می‌تواند یک رشته، یک عدد، یک مقدار بولی، یک نگاشت یا یک آرایه باشد. یک نگاشت صرفاً مجموعه‌ای از جفت‌های نام/مقدار است. مقدار هر یک از این نوع ادعاها را می‌توان به صراحت در پیکربندی سیاست یا به طور غیرمستقیم از طریق ارجاع به یک متغیر جریان مشخص کرد.

عنصر <Claim> این ویژگی‌ها را می‌پذیرد:

• نام - (الزامی) نام ادعا.
• ref - (اختیاری) نام یک متغیر جریان. در صورت وجود، سیاست از مقدار این متغیر به عنوان ادعا استفاده خواهد کرد. اگر هم ویژگی ref و هم مقدار ادعای صریح مشخص شده باشند، مقدار صریح پیش‌فرض است و در صورتی استفاده می‌شود که متغیر جریان ارجاع داده شده حل نشده باشد.
• نوع - (اختیاری) یکی از: رشته (پیش‌فرض)، عدد، بولی یا نقشه
• آرایه - (اختیاری) برای نشان دادن اینکه آیا مقدار، آرایه‌ای از انواع است یا خیر، روی true تنظیم می‌شود. پیش‌فرض: false.

<ادعاهای سفارشی>

نکته: در حال حاضر، وقتی یک سیاست GenerateJWT جدید را از طریق رابط کاربری اضافه می‌کنید، یک عنصر CustomClaims اضافه می‌شود. این عنصر کاربردی نیست و نادیده گرفته می‌شود. عنصر صحیح برای استفاده، <AdditionalClaims> است. رابط کاربری بعداً برای اضافه کردن عناصر صحیح به‌روزرسانی خواهد شد.

<شناسه>

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

تأیید می‌کند که JWT ادعای jti خاص را دارد. وقتی مقدار متن و ویژگی ref هر دو خالی باشند، این سیاست یک jti حاوی یک UUID تصادفی تولید می‌کند. ادعای JWT ID (jti) یک شناسه منحصر به فرد برای JWT است. برای اطلاعات بیشتر در مورد jti، به RFC7519 مراجعه کنید.

<نادیده گرفتن هدرهای بحرانی>

<IgnoreCriticalHeaders>true|false</IgnoreCriticalHeaders>

اگر می‌خواهید سیاست در صورت عدم وجود هر سرآیند ذکر شده در سرآیند crit از JWT در عنصر <KnownHeaders> ، خطا صادر کند، آن را روی false تنظیم کنید. اگر می‌خواهید سیاست VerifyJWT سرآیند crit را نادیده بگیرد، آن را روی true تنظیم کنید.

یکی از دلایل تنظیم این عنصر روی مقدار true این است که اگر در یک محیط آزمایشی هستید و هنوز آماده نیستید که یک خطا را روی یک هدر از دست رفته ایجاد کنید.

<نادیده گرفتن صدور>

<IgnoreIssuedAt>true|false</IgnoreIssuedAt>

اگر می‌خواهید سیاست زمانی که JWT حاوی یک ادعای iat (صادر شده در) است که زمانی را در آینده مشخص می‌کند، خطا صادر کند، روی false (پیش‌فرض) تنظیم کنید. برای اینکه سیاست در حین تأیید، iat را نادیده بگیرد، روی true تنظیم کنید.

<نادیده گرفتن متغیرهای حل نشده>

<IgnoreUnresolvedVariables>true|false</IgnoreUnresolvedVariables>

اگر می‌خواهید سیاست در صورت غیرقابل حل بودن هر متغیر ارجاع‌شده در سیاست، خطا صادر کند، روی false تنظیم کنید. اگر می‌خواهید هر متغیر غیرقابل حل را به عنوان یک رشته خالی (null) در نظر بگیرید، روی true تنظیم کنید.

<صادرکننده>

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

این خط‌مشی تأیید می‌کند که صادرکننده‌ی JWT با رشته‌ی مشخص‌شده در عنصر پیکربندی مطابقت دارد. ادعایی که صادرکننده‌ی JWT را شناسایی می‌کند. این یکی از مجموعه ادعاهای ثبت‌شده‌ی ذکر شده در RFC7519 است.

<سربرگ‌های شناخته‌شده>

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

or:

<KnownHeaders ref=’variable_containing_headers’/>

سیاست GenerateJWT از عنصر <CriticalHeaders> برای پر کردن هدر crit در یک JWT استفاده می‌کند. برای مثال:

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

سیاست VerifyJWT در صورت وجود، هدر crit را در JWT بررسی می‌کند و برای هر هدر فهرست‌شده، بررسی می‌کند که آیا عنصر <KnownHeaders> نیز آن هدر را فهرست کرده است یا خیر. عنصر <KnownHeaders> می‌تواند شامل مجموعه‌ای از موارد فهرست‌شده در crit باشد. فقط لازم است که تمام هدرهای فهرست‌شده در crit در عنصر <KnownHeaders> فهرست شده باشند. هر هدری که این سیاست در crit پیدا کند و در <KnownHeaders> نیز فهرست نشده باشد، باعث می‌شود که سیاست VerifyJWT با شکست مواجه شود.

شما می‌توانید به صورت اختیاری با تنظیم عنصر <IgnoreCriticalHeaders> روی true ، سیاست VerifyJWT را طوری پیکربندی کنید که هدر crit را نادیده بگیرد.

<کلید عمومی/گواهی>

<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 باشد.

<کلید عمومی/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 استفاده خواهد کرد. برای جزئیات بیشتر در مورد این ویژگی، به استفاده از مجموعه کلید وب JSON (JWKS) برای تأیید JWT مراجعه کنید.

اگر مقدار را از یک URL عمومی دریافت کنید، Edge فایل JWKS را به مدت ۳۰۰ ثانیه ذخیره می‌کند. وقتی مدت زمان ذخیره به پایان برسد، Edge دوباره JWKS را دریافت می‌کند.

<کلید عمومی/مقدار>

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

کلید مخفی مورد استفاده برای تأیید یا امضای توکن‌ها با الگوریتم HMAC را ارائه می‌دهد. فقط زمانی استفاده می‌شود که الگوریتم یکی از HS256، HS384، HS512 باشد .

<منبع>

<Source>jwt-variable</Source>

در صورت وجود، متغیر جریانی را مشخص می‌کند که در آن سیاست انتظار دارد JWT را برای تأیید پیدا کند.

<موضوع>

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

این سیاست تأیید می‌کند که موضوع JWT با رشته مشخص شده در پیکربندی سیاست مطابقت دارد. این ادعا، موضوع JWT را شناسایی یا در مورد آن اظهار نظر می‌کند. این یکی از مجموعه ادعاهای استاندارد ذکر شده در RFC7519 است.

<زمان مجاز>

<TimeAllowance>120s</TimeAllowance>

«دوره مجاز» برای زمان‌ها. برای مثال، اگر مهلت زمانی روی ۶۰ ثانیه پیکربندی شده باشد، یک JWT منقضی شده به مدت ۶۰ ثانیه پس از انقضای ادعا شده، همچنان معتبر تلقی می‌شود. مدت زمان قبل از انقضا نیز به طور مشابه ارزیابی خواهد شد. پیش‌فرض روی ۰ ثانیه (بدون دوره مجاز) است.

متغیرهای جریان

پس از موفقیت، سیاست های 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>
    

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

چه

امضای JWT دریافتی از کلاینت‌ها یا سایر سیستم‌ها را تأیید می‌کند. این خط‌مشی همچنین ادعاها را در متغیرهای زمینه‌ای استخراج می‌کند تا خط‌مشی‌ها یا شرایط بعدی بتوانند آن مقادیر را برای تصمیم‌گیری در مورد مجوز یا مسیریابی بررسی کنند. برای مقدمه‌ای مفصل ، به نمای کلی خط‌مشی‌های JWS و JWT مراجعه کنید.

وقتی این سیاست اجرا می‌شود، Edge امضای یک JWT را تأیید می‌کند و اعتبار JWT را بر اساس زمان‌های انقضا و عدم وجود آنها در صورت وجود، تأیید می‌کند. این سیاست می‌تواند به صورت اختیاری مقادیر ادعاهای خاص در JWT، مانند موضوع، صادرکننده، مخاطب یا ارزش ادعاهای اضافی را نیز تأیید کند.

اگر JWT تأیید و معتبر باشد، تمام ادعاهای موجود در JWT برای استفاده توسط سیاست‌ها یا شرایط بعدی به متغیرهای زمینه‌ای استخراج می‌شوند و درخواست اجازه ادامه پیدا می‌کند. اگر امضای JWT قابل تأیید نباشد یا اگر JWT به دلیل یکی از مهرهای زمانی نامعتبر باشد، تمام پردازش متوقف می‌شود و خطایی در پاسخ برگردانده می‌شود.

برای کسب اطلاعات در مورد اجزای یک JWT و نحوه رمزگذاری و امضای آنها، به RFC7519 مراجعه کنید.

ویدئو

برای یادگیری نحوه تأیید امضا در JWT، یک ویدیوی کوتاه تماشا کنید.

نمونه‌ها

• تأیید یک JWT امضا شده با الگوریتم HS256
• تأیید یک JWT امضا شده با الگوریتم RS256

تأیید یک JWT امضا شده با الگوریتم HS256

این سیاست نمونه، یک JWT را که با الگوریتم رمزگذاری HS256، HMAC با استفاده از SHA-256 checksum امضا شده است، تأیید می‌کند. JWT با استفاده از یک پارامتر فرم به نام jwt در درخواست پروکسی ارسال می‌شود. کلید در متغیری به نام private.secretkey قرار دارد. برای مثال کامل، از جمله نحوه ارسال درخواست به این سیاست، به ویدیوی بالا مراجعه کنید.

پیکربندی سیاست شامل اطلاعاتی است که Edge برای رمزگشایی و ارزیابی JWT نیاز دارد، مانند محل یافتن JWT (در یک متغیر جریان مشخص شده در عنصر Source)، الگوریتم امضای مورد نیاز، محل یافتن کلید مخفی (ذخیره شده در یک متغیر جریان 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>

این خط‌مشی خروجی خود را در متغیرهای زمینه می‌نویسد تا خط‌مشی‌ها یا شرایط بعدی در پروکسی API بتوانند آن مقادیر را بررسی کنند. برای فهرستی از متغیرهای تنظیم‌شده توسط این خط‌مشی، به متغیرهای جریان مراجعه کنید.

تأیید یک JWT امضا شده با الگوریتم RS256

این سیاست نمونه، یک 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 با همان هدر اما با این payload ...

{ 
  "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."
}

... نامعتبر تشخیص داده خواهد شد، حتی اگر امضا قابل تأیید باشد، زیرا ادعای "sub" موجود در JWT با مقدار مورد نیاز عنصر "Subject" که در پیکربندی خط‌مشی مشخص شده است، مطابقت ندارد.

این خط‌مشی خروجی خود را در متغیرهای زمینه می‌نویسد تا خط‌مشی‌ها یا شرایط بعدی در پروکسی API بتوانند آن مقادیر را بررسی کنند. برای فهرستی از متغیرهای تنظیم‌شده توسط این خط‌مشی، به متغیرهای جریان مراجعه کنید.

تنظیم عناصر کلیدی

عناصری که برای مشخص کردن کلید مورد استفاده برای تأیید 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>Policy Display Name</DisplayName>

علاوه بر ویژگی نام، از این ویژگی برای برچسب‌گذاری سیاست در ویرایشگر پروکسی رابط کاربری مدیریت با یک نام متفاوت به زبان طبیعی استفاده کنید.

<الگوریتم>

<Algorithm>HS256</Algorithm>

الگوریتم رمزگذاری برای امضای توکن را مشخص می‌کند. الگوریتم‌های RS*/PS*/ES* از یک جفت کلید عمومی/مخفی استفاده می‌کنند، در حالی که الگوریتم‌های HS* از یک کلید مخفی مشترک استفاده می‌کنند. همچنین به «درباره الگوریتم‌های رمزگذاری امضا» مراجعه کنید.

شما می‌توانید چندین مقدار را که با کاما از هم جدا شده‌اند، مشخص کنید. برای مثال "HS256، HS512" یا "RS256، PS256". با این حال، نمی‌توانید الگوریتم‌های HS* را با هیچ الگوریتم دیگری یا الگوریتم‌های ES* را با هیچ الگوریتم دیگری ترکیب کنید زیرا به یک نوع کلید خاص نیاز دارند. می‌توانید الگوریتم‌های RS* و PS* را با هم ترکیب کنید.

<مخاطب>

<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 payload شامل claim(s) اضافی مشخص شده است و مقادیر claim ادعا شده مطابقت دارند.

یک ادعای اضافی از نامی استفاده می‌کند که جزو نام‌های ادعای استاندارد و ثبت‌شده‌ی JWT نیست. مقدار یک ادعای اضافی می‌تواند یک رشته، عدد، مقدار بولی، نگاشت یا آرایه باشد. یک نگاشت صرفاً مجموعه‌ای از جفت‌های نام/مقدار است. مقدار هر یک از این نوع ادعاها را می‌توان به صراحت در پیکربندی سیاست یا به طور غیرمستقیم از طریق ارجاع به یک متغیر جریان مشخص کرد.

عنصر <Claim> این ویژگی‌ها را می‌پذیرد:

• نام - (الزامی) نام ادعا.
• ref - (اختیاری) نام یک متغیر جریان. در صورت وجود، سیاست از مقدار این متغیر به عنوان ادعا استفاده خواهد کرد. اگر هم ویژگی ref و هم مقدار ادعای صریح مشخص شده باشند، مقدار صریح پیش‌فرض است و در صورتی استفاده می‌شود که متغیر جریان ارجاع داده شده حل نشده باشد.
• نوع - (اختیاری) یکی از: رشته (پیش‌فرض)، عدد، بولی یا نقشه
• آرایه - (اختیاری) برای نشان دادن اینکه آیا مقدار، آرایه‌ای از انواع است یا خیر، روی 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 نیست. مقدار یک ادعای اضافی می‌تواند یک رشته، یک عدد، یک مقدار بولی، یک نگاشت یا یک آرایه باشد. یک نگاشت صرفاً مجموعه‌ای از جفت‌های نام/مقدار است. مقدار هر یک از این نوع ادعاها را می‌توان به صراحت در پیکربندی سیاست یا به طور غیرمستقیم از طریق ارجاع به یک متغیر جریان مشخص کرد.

عنصر <Claim> این ویژگی‌ها را می‌پذیرد:

• نام - (الزامی) نام ادعا.
• ref - (اختیاری) نام یک متغیر جریان. در صورت وجود، سیاست از مقدار این متغیر به عنوان ادعا استفاده خواهد کرد. اگر هم ویژگی ref و هم مقدار ادعای صریح مشخص شده باشند، مقدار صریح پیش‌فرض است و در صورتی استفاده می‌شود که متغیر جریان ارجاع داده شده حل نشده باشد.
• نوع - (اختیاری) یکی از: رشته (پیش‌فرض)، عدد، بولی یا نقشه
• آرایه - (اختیاری) برای نشان دادن اینکه آیا مقدار، آرایه‌ای از انواع است یا خیر، روی true تنظیم می‌شود. پیش‌فرض: false.

<ادعاهای سفارشی>

نکته: در حال حاضر، وقتی یک سیاست GenerateJWT جدید را از طریق رابط کاربری اضافه می‌کنید، یک عنصر CustomClaims اضافه می‌شود. این عنصر کاربردی نیست و نادیده گرفته می‌شود. عنصر صحیح برای استفاده، <AdditionalClaims> است. رابط کاربری بعداً برای اضافه کردن عناصر صحیح به‌روزرسانی خواهد شد.

<شناسه>

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

تأیید می‌کند که JWT ادعای jti خاص را دارد. وقتی مقدار متن و ویژگی ref هر دو خالی باشند، این سیاست یک jti حاوی یک UUID تصادفی تولید می‌کند. ادعای JWT ID (jti) یک شناسه منحصر به فرد برای JWT است. برای اطلاعات بیشتر در مورد jti، به RFC7519 مراجعه کنید.

<نادیده گرفتن هدرهای بحرانی>

<IgnoreCriticalHeaders>true|false</IgnoreCriticalHeaders>

اگر می‌خواهید سیاست در صورت عدم وجود هر سرآیند ذکر شده در سرآیند crit از JWT در عنصر <KnownHeaders> ، خطا صادر کند، آن را روی false تنظیم کنید. اگر می‌خواهید سیاست VerifyJWT سرآیند crit را نادیده بگیرد، آن را روی true تنظیم کنید.

یکی از دلایل تنظیم این عنصر روی مقدار true این است که اگر در یک محیط آزمایشی هستید و هنوز آماده نیستید که یک خطا را روی یک هدر از دست رفته ایجاد کنید.

<نادیده گرفتن صدور>

<IgnoreIssuedAt>true|false</IgnoreIssuedAt>

اگر می‌خواهید سیاست زمانی که JWT حاوی یک ادعای iat (صادر شده در) است که زمانی را در آینده مشخص می‌کند، خطا صادر کند، روی false (پیش‌فرض) تنظیم کنید. برای اینکه سیاست در حین تأیید، iat را نادیده بگیرد، روی true تنظیم کنید.

<نادیده گرفتن متغیرهای حل نشده>

<IgnoreUnresolvedVariables>true|false</IgnoreUnresolvedVariables>

اگر می‌خواهید سیاست در صورت غیرقابل حل بودن هر متغیر ارجاع‌شده در سیاست، خطا صادر کند، روی false تنظیم کنید. اگر می‌خواهید هر متغیر غیرقابل حل را به عنوان یک رشته خالی (null) در نظر بگیرید، روی true تنظیم کنید.

<صادرکننده>

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

این خط‌مشی تأیید می‌کند که صادرکننده‌ی JWT با رشته‌ی مشخص‌شده در عنصر پیکربندی مطابقت دارد. ادعایی که صادرکننده‌ی JWT را شناسایی می‌کند. این یکی از مجموعه ادعاهای ثبت‌شده‌ی ذکر شده در RFC7519 است.

<سربرگ‌های شناخته‌شده>

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

or:

<KnownHeaders ref=’variable_containing_headers’/>

سیاست GenerateJWT از عنصر <CriticalHeaders> برای پر کردن هدر crit در یک JWT استفاده می‌کند. برای مثال:

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

سیاست VerifyJWT در صورت وجود، هدر crit را در JWT بررسی می‌کند و برای هر هدر فهرست‌شده، بررسی می‌کند که آیا عنصر <KnownHeaders> نیز آن هدر را فهرست کرده است یا خیر. عنصر <KnownHeaders> می‌تواند شامل مجموعه‌ای از موارد فهرست‌شده در crit باشد. فقط لازم است که تمام هدرهای فهرست‌شده در crit در عنصر <KnownHeaders> فهرست شده باشند. هر هدری که این سیاست در crit پیدا کند و در <KnownHeaders> نیز فهرست نشده باشد، باعث می‌شود که سیاست VerifyJWT با شکست مواجه شود.

شما می‌توانید به صورت اختیاری با تنظیم عنصر <IgnoreCriticalHeaders> روی true ، سیاست VerifyJWT را طوری پیکربندی کنید که هدر crit را نادیده بگیرد.

<کلید عمومی/گواهی>

<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 باشد.

<کلید عمومی/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 استفاده خواهد کرد. برای جزئیات بیشتر در مورد این ویژگی، به استفاده از مجموعه کلید وب JSON (JWKS) برای تأیید JWT مراجعه کنید.

اگر مقدار را از یک URL عمومی دریافت کنید، Edge فایل JWKS را به مدت ۳۰۰ ثانیه ذخیره می‌کند. وقتی مدت زمان ذخیره به پایان برسد، Edge دوباره JWKS را دریافت می‌کند.

<کلید عمومی/مقدار>

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

کلید مخفی مورد استفاده برای تأیید یا امضای توکن‌ها با الگوریتم HMAC را ارائه می‌دهد. فقط زمانی استفاده می‌شود که الگوریتم یکی از HS256، HS384، HS512 باشد .

<منبع>

<Source>jwt-variable</Source>

در صورت وجود، متغیر جریانی را مشخص می‌کند که در آن سیاست انتظار دارد JWT را برای تأیید پیدا کند.

<موضوع>

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

این سیاست تأیید می‌کند که موضوع JWT با رشته مشخص شده در پیکربندی سیاست مطابقت دارد. این ادعا، موضوع JWT را شناسایی یا در مورد آن اظهار نظر می‌کند. این یکی از مجموعه ادعاهای استاندارد ذکر شده در RFC7519 است.

<زمان مجاز>

<TimeAllowance>120s</TimeAllowance>

«دوره مجاز» برای زمان‌ها. برای مثال، اگر مهلت زمانی روی ۶۰ ثانیه پیکربندی شده باشد، یک JWT منقضی شده به مدت ۶۰ ثانیه پس از انقضای ادعا شده، همچنان معتبر تلقی می‌شود. مدت زمان قبل از انقضا نیز به طور مشابه ارزیابی خواهد شد. پیش‌فرض روی ۰ ثانیه (بدون دوره مجاز) است.

متغیرهای جریان

پس از موفقیت، سیاست های 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>