[security-dev 00754]: Re: Code review request: Undefined requesting URL in "java.net.Authenticator.getPasswordAuthentication()"

Max Wang Weijun.Wang at Sun.COM
Wed Apr 15 10:52:05 UTC 2009


Hi Chris

A new webrev is created at
     http://cr.openjdk.java.net/~weijun/6578647/webrev.01

Now all HttpCallerInfo creations are inline, so the diff is much  
clearer. There's one place I didn't call toLowerCase(), the call is  
moved into NegotiatorImpl right before the service principal name is  
created.

I also add a test, putting two Kerberos KDC, one HTTP server, one  
proxy server in a single regression test is fun!

Thanks
Mx

On Apr 14, 2009, at 8:55 PM, Max (Weijun) Wang wrote:

>
> On Apr 14, 2009, at 5:59 PM, Christopher Hegarty - Sun Microsystems  
> Ireland wrote:
>
>> Hi Max,
>>
>> I only looked at the networking part of the changes. They look  
>> fine, I just have a few questions/comments:
>>
>> 1) sun.net.www.protocol.http.HttpURLConnection
>>  Can you use the same HttpCallerInfo instance for proxy  
>> authentication
>>  at line 1108? This instance has been created using the single arg
>>  constructor therefore it is has authType = RequestorType.SERVER,
>>  right?
>
> Yes, you're right. Will update tomorrow.
>
>>
>> 2) sun.net.www.protocol.http.HttpCallerInfo
>>  It is just my preference, but I would prefer to see all the fields  
>> of
>>  HttpCallerInfo private and have simple accessors:
>>      private final String host;
>>      ......
>>
>>      public String host() {
>>          return host;
>>      }
>>      ......
>
> Your suggestion is more formal. But I think making all fields final  
> is also sufficient to make it immutable.
>
>>
>> 3) Are the changes to use HttpCallerInfo in AuthenticationHeader,
>>  HttpURLConnection, NegotiateAuthentication and NegotiatorImpl
>>  strictly necessary? They seem to be changed just for consistency of
>>  using the new class. I only see that NegotiateCallbackHandler is
>>  required to use this new class on the networking side.
>
> There needs a way to transfer these info into the JGSS underneath  
> (so that NegotiateCallbackHandler has a chance to know them), and  
> the only bridge is inside NegotiatorImpl. I don't know if there's a  
> better way to do this. The HttpClient class seems having similar  
> info but sometimes it's null and I don't know why. Sorry if I  
> reinvent a wheel-cart to carry these info.
>
> Thanks
> Max
>
>>
>>  This is not a problem just a question to see if I understand
>>  correctly the changes.
>>
>> -Chris.
>>
>>
>>
>>
>>
>> On 04/13/09 03:27, Weijun Wang wrote:
>>> Hi Valerie and Networking guys
>>> Please take a review at this bug fix:
>>>   http://cr.openjdk.java.net/~weijun/6578647/webrev.00/
>>> The bug is
>>>   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578647
>>> The bug report says that no URL-related info is available in
>>> Authenticator when using HTTP/Negotiate. The reason is that in the  
>>> long
>>> stack of
>>>  HTTP/Negotiate -> JGSS -> JAAS -> Krb5LoginModule
>>>      -> Callback -> Authenticator
>>> The URL info is lost. In order to support special actions for
>>> HTTP/Negotiate calls in JGSS (say, using Authenticator instead of
>>> text-based callback, honor the OK-AS-DELEGATE flag...), we already  
>>> used
>>> an integer field (caller) to tell the codes deep below who  
>>> initiates the
>>> JGSS calls. It seems an integer is not enough to carry too much
>>> information. (oh, I love the C void*)
>>> The fix is simple: change the caller from integer to a Java class:
>>> GSSCaller, which includes as much as info it likes. For HTTP/ 
>>> Negotiate,
>>> a child class HttpCaller, encapsulates all info an Authenticator  
>>> needs.
>>> The fix includes three parts:
>>> 1. Three new classes:
>>>  sun.sec.jgss.GSSCaller:
>>>      the new caller
>>>  sun.sec.jgss.HttpCaller:
>>>      a child of GSSCaller, knows everything about HTTP
>>>  sun.net.www.protocol.http.HttpCallerInfo:
>>>      the info GSSCaller knows, this class is created on the
>>>      network side so that no sun.security.jgss.* codes are
>>>      dragged into the bootstrap building process.
>>> 2. On the network side:
>>>  Refactoring HTTP codes in sun.net.www.protocol.http.* to fill info
>>>  into the HttpCallerInfo class.
>>> 3. On the JGSS side:
>>>  Multiple changes in sun.security.jgss.* classes. *All* the
>>>  code changes are simply s/int/GSSCaller/g changes.
>>>  I also moved the pre-defined callers from GSSUtil to
>>>  GSSCaller.
>>> Thanks
>>> Max
>




More information about the security-dev mailing list