Jetty 12.0.x SPNEGO: نام سرویس را تنظیم کنید، نه principal کامل

در پیکربندی SPNEGO در Jetty سه نام وجود دارد: URI که برای تطبیق احراز هویت استفاده می‌شود، کاربری که از طریق JAAS وارد می‌شود و سرویسی که برای آن بلیت درخواست می‌شود. هر یک هدف متفاوتی دارند.

برای پیاده‌سازی Jetty 12.0.x، قطعه‌ای از شیء احراز هویت چنین است:

var auth = new org.eclipse.jetty.client.SPNEGOAuthentication(
    java.net.URI.create("http://proxy.example:8080"));
auth.setServiceName("HTTP");

این قطعه مؤلفه سرویس را نشان می‌دهد، نه دستور کامل احراز هویت پروکسی. ورود JAAS، مسیریابی پروکسی و تبادل احراز هویت درخواست جدا باقی می‌مانند.

در این پیاده‌سازی Jetty نام میزبان‌محور GSS را با ترکیب getServiceName()، نویسه @ و میزبان تبادل احراز هویت می‌سازد. اگر [email protected] را به‌عنوان مؤلفه سرویس بدهید، میزبان دیگری افزوده می‌شود. قرارداد این setter را بخوانید، نه اینکه فرض کنید principal کامل Kerberos را می‌پذیرد.

نام GSS حاصل شکل مفهومی HTTP@hostname دارد. principal سرویس متناظر در KDC معمولاً به صورت HTTP/hostname نمایش داده می‌شود. نام پروکسی انتخاب‌شده باید با سرویس واقعاً ثبت‌شده مطابقت داشته باشد برای آن حساب؛ یک نشانی IP یا نام مستعار می‌تواند هدف بلیت دیگری را انتخاب کند.

مسیر 407 را هم بررسی کنید

در Jetty 12.0.x، authenticate() نام میزبان GSS را از request.getHost() می‌گیرد و با سرصفحه پیش‌فرض Authorization نتیجه می‌سازد. تطبیق شیء احراز هویت بر اساس URI پروکسی به‌خودی‌خود آن انتخاب‌ها را به نام میزبان پروکسی و Proxy-Authorization تغییر نمی‌دهد.

بنابراین یکپارچه‌سازی پروکسی برای آن تبادل به میزبان درخواست درست و نتیجهٔ محدود به پروکسی نیاز دارد. درخواست HTTPS CONNECT و درخواست عادی به مبدأ می‌توانند مقادیر میزبان متفاوتی داشته باشند. رفتار پیاده‌سازی نصب‌شده را تأیید کنید، نه اینکه فرض کنید setter نام سرویس جریان کامل 407 را فراهم می‌کند.

برای 407، تبادل احراز هویت پروکسی و میزبان استفاده‌شده در آن درخواست را بررسی کنید. 401 به احراز هویت مبدأ تعلق دارد. بلیت معتبر کاربر به‌تنهایی ثابت نمی‌کند که Jetty بلیت سرویس درست را خواسته یا واسطه آن را پذیرفته است.