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 getServiceName(), একটি @ অক্ষর এবং প্রমাণীকরণ বিনিময়ের হোস্ট একত্র করে GSS হোস্টভিত্তিক নাম তৈরি করে। [email protected] কে পরিষেবা উপাদান হিসেবে দিলে আরেকটি হোস্ট যুক্ত হবে। এই সেটার সম্পূর্ণ Kerberos principal গ্রহণ করে ধরে নেওয়ার বদলে এর চুক্তি পড়ুন।

ফলাফল GSS নামের ধারণাগত রূপ HTTP@hostname। KDC-এর সংশ্লিষ্ট পরিষেবা principal সাধারণত HTTP/hostname হিসেবে উপস্থাপিত হয়। নির্বাচিত proxy নামটি প্রকৃতপক্ষে নিবন্ধিত পরিষেবার সঙ্গে মিলতে হবে সেই অ্যাকাউন্টের জন্য; IP ঠিকানা বা উপনাম অন্য টিকিট লক্ষ্য বাছতে পারে।

407 পথটিও পরীক্ষা করুন

Jetty 12.0.x-এ authenticate() request.getHost() থেকে GSS হোস্টনাম নেয় এবং ডিফল্ট Authorization হেডার ব্যবহার করে ফলাফল তৈরি করে। proxy URI দিয়ে প্রমাণীকরণ অবজেক্ট মেলানো নিজে থেকে সেই পছন্দগুলোকে proxy-র হোস্টনাম ও Proxy-Authorization-এ বদলায় না।

তাই proxy সংহতকরণের জন্য সেই বিনিময়ের সঠিক অনুরোধ-হোস্ট ও proxy-সীমিত ফলাফল দরকার। একটি HTTPS CONNECT অনুরোধ ও একটি সাধারণ মূল অনুরোধের হোস্ট মান আলাদা হতে পারে। পরিষেবা-নাম সেটার সম্পূর্ণ 407 প্রবাহ দেয় ধরে নেওয়ার বদলে ইনস্টল করা বাস্তবায়নের আচরণ যাচাই করুন।

407-এর ক্ষেত্রে, সেই অনুরোধের proxy প্রমাণীকরণ বিনিময় ও ব্যবহৃত হোস্ট পরীক্ষা করুন। 401 মূল প্রমাণীকরণের। কেবল একটি বৈধ ব্যবহারকারী টিকিট প্রমাণ করে না যে Jetty সঠিক পরিষেবা টিকিট চেয়েছে বা মধ্যস্থকারী তা গ্রহণ করেছে।