Jetty 12.0.x SPNEGO: سروس کا نام مقرر کریں، مکمل principal نہیں

Jetty SPNEGO ترتیب میں تین نام ہوتے ہیں: توثیق ملانے کے لیے استعمال ہونے والا 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");

یہ حصہ سروس کے جزو کو ظاہر کرتا ہے، مکمل proxy توثیق کا نسخہ نہیں۔ JAAS لاگ اِن، proxy روٹنگ اور درخواست کی توثیقی تبادلہ الگ ہی رہتے ہیں۔

اس نفاذ میں Jetty GSS میزبان پر مبنی نام getServiceName()، @ حرف اور توثیقی تبادلے کے میزبان کو ملا کر بناتا ہے۔ [email protected] کو سروس جزو کے طور پر دینے سے ایک اور میزبان شامل ہو جائے گا۔ یہ سمجھنے کے بجائے کہ یہ مکمل Kerberos principal قبول کرتا ہے، اس setter کا معاہدہ پڑھیں۔

نتیجے میں بننے والے GSS نام کی تصوراتی شکل HTTP@hostname ہے۔ KDC کا متعلقہ سروس principal عموماً HTTP/hostname کے طور پر ظاہر کیا جاتا ہے۔ منتخب کردہ proxy نام کو واقعی رجسٹرڈ سروس سے مطابقت رکھنی چاہیے اُس اکاؤنٹ کے لیے؛ IP پتہ یا عرف کسی دوسرے ٹکٹ ہدف کا انتخاب کر سکتا ہے۔

407 کا راستہ بھی جانچیں

Jetty 12.0.x میں authenticate() GSS میزبان نام request.getHost() سے لیتا ہے اور طے شدہ Authorization ہیڈر کے ساتھ نتیجہ بناتا ہے۔ proxy URI کے مطابق توثیقی آبجیکٹ ملانا بذات خود اِن انتخابات کو proxy کے میزبان نام اور Proxy-Authorization میں نہیں بدلتا۔

لہٰذا proxy انضمام کو اُس تبادلے کے لیے درست درخواست میزبان اور proxy کے دائرے میں نتیجہ درکار ہے۔ HTTPS CONNECT درخواست اور عام اصل درخواست کے میزبان کی قدریں مختلف ہو سکتی ہیں۔ یہ سمجھنے کے بجائے کہ سروس نام والا setter مکمل 407 بہاؤ فراہم کرتا ہے، نصب شدہ نفاذ کا رویہ تصدیق کریں۔

407 کے لیے، اُس درخواست کا استعمال کردہ proxy توثیقی تبادلہ اور میزبان جانچیں۔ 401 اصل توثیق سے تعلق رکھتا ہے۔ صرف درست صارف ٹکٹ یہ ثابت نہیں کرتا کہ Jetty نے صحیح سروس ٹکٹ مانگا یا درمیانی نے اُسے قبول کیا۔