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

[Christopher Hegarty - Sun Microsystems Ireland]

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?

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;
        }
        ......

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.

    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