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");

קטע זה ממחיש את רכיב השירות, ולא מתכון מלא לאימות proxy. כניסת JAAS, ניתוב ה-proxy והחלפת האימות של הבקשה נשארים נפרדים.

ביישום זה Jetty בונה את שם ה-GSS המבוסס על המארח על ידי שילוב getServiceName(), התו @ והמארח של החלפת האימות. מסירת [email protected] כרכיב שירות תוסיף מארח נוסף. קראו את החוזה של setter זה במקום להניח שהוא מקבל principal מלא של Kerberos.

לשם ה-GSS המתקבל יש הצורה המושגית HTTP@hostname. ה-principal המתאים של השירות ב-KDC מיוצג בדרך כלל כ-HTTP/hostname. ה-שם ה-proxy שנבחר חייב להתאים לשירות שנרשם בפועל עבור אותו חשבון; כתובת IP או כינוי עשויים לבחור יעד כרטיס אחר.

בדקו גם את מסלול 407

ב-Jetty 12.0.x ‏authenticate() מקבל את שם המארח של GSS מ-request.getHost() ובונה תוצאה עם כותרת Authorization המוגדרת כברירת מחדל. התאמת אובייקט אימות לפי URI של proxy אינה משנה בעצמה את הבחירות האלה לשם המארח של ה-proxy ול-Proxy-Authorization.

לכן שילוב proxy זקוק למארח הבקשה הנכון ולתוצאה בתחום ה-proxy עבור החלפה זו. בקשת HTTPS CONNECT ובקשת מקור רגילה עשויות להיות בעלות ערכי מארח שונים. אשרו את התנהגות היישום המותקן במקום להניח שה-setter של שם השירות מספק את זרימת ה-407 המלאה.

עבור 407, בדקו את החלפת האימות של ה-proxy ואת המארח ששימש את הבקשה. 401 שייך לאימות המקור. כרטיס משתמש תקף לבדו אינו מוכיח ש-Jetty ביקש את כרטיס השירות הנכון או שהמתווך קיבל אותו.