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 ను అంగీకరిస్తుందని భావించకుండా ఈ setter యొక్క ఒప్పందాన్ని చదవండి.

ఫలిత 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 అభ్యర్థన మరియు సాధారణ మూల అభ్యర్థన వేర్వేరు హోస్ట్ విలువలను కలిగి ఉండవచ్చు. సేవా-పేరు setter పూర్తి 407 ప్రవాహాన్ని అందిస్తుందని భావించకుండా ఇన్స్టాల్ చేసిన అమలు ప్రవర్తనను నిర్ధారించండి.

407 కోసం, ఆ అభ్యర్థన ఉపయోగించిన proxy ప్రమాణీకరణ మార్పిడి మరియు హోస్ట్ను పరిశీలించండి. 401 మూల ప్రమాణీకరణకు చెందుతుంది. చెల్లుబాటు అయ్యే వినియోగదారు టికెట్ మాత్రమే Jetty సరైన సేవా టికెట్ను కోరిందని లేదా మధ్యవర్తి దాన్ని అంగీకరించిందని నిరూపించదు.