[jetty-dev] Missing WWW-Authenticate from SpnegoAuthenticator when other Authorization header provided

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[jetty-dev] Missing WWW-Authenticate from SpnegoAuthenticator when other Authorization header provided

Josh Elser
Hi all,

I've been digging into an interesting case I'd like to run by you all.

I have a Jetty application that requires SPNEGO authentication sitting
behind a reverse-proxy that requires HTTP Basic authentication (clients
use Basic auth to talk to the reverse-proxy and the reverse-proxy uses
SPNEGO to talk to the Jetty application). The problem was that the
reverse-proxy was failing to authenticate with the Jetty application.

Digging further, I noticed that the reverse-proxy does not strip the
HTTP Basic Authorization header sent by the client. When Jetty see that
request, it does not send back the expected HTTP/401 with a
WWW-Negotiate header. I just seem a plain HTTP/401 that comes from
application (as the user was not authenticated).

Looking at the source of SpnegoAuthenticator[1], the negotiate challenge
will _only_ be sent when no Authorization headed was sent by the client.
This seemed a bit odd to me, so I re-read RFC-4559[2], section 4.1:

<quote>
If the server receives a request for an access-protected object, and
if an acceptable Authorization header has not been sent, the server
responds with a "401 Unauthorized" status code, and a "WWW-
Authenticate: Negotiate" header as per the framework described in [RFC2616].
</quote>

Given the above, my initial interpretation was that if a client provides
some Authorization header which is not sufficient for SPNEGO
authentication, SpnegoAuthenticator should sent the challenge request.
That is not the case -- SpnegoAuthenticator will only send the challenge
request when _no_ Authorization header is provided.

I wanted to drop a note because I can imagine that there are edge-cases
which I'm not considering. Thanks in advance!


- Josh

[1]
https://github.com/eclipse/jetty.project/blob/0c8273f2ca1f9bf2064cd9c4c939d2546443f759/jetty-security/src/main/java/org/eclipse/jetty/security/authentication/SpnegoAuthenticator.java#L76-L94
[2] https://tools.ietf.org/html/rfc4559
_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Missing WWW-Authenticate from SpnegoAuthenticator when other Authorization header provided

Joakim Erdfelt-8

Joakim Erdfelt / [hidden email]

On Thu, Jul 27, 2017 at 1:18 PM, Josh Elser <[hidden email]> wrote:
Hi all,

I've been digging into an interesting case I'd like to run by you all.

I have a Jetty application that requires SPNEGO authentication sitting behind a reverse-proxy that requires HTTP Basic authentication (clients use Basic auth to talk to the reverse-proxy and the reverse-proxy uses SPNEGO to talk to the Jetty application). The problem was that the reverse-proxy was failing to authenticate with the Jetty application.

Digging further, I noticed that the reverse-proxy does not strip the HTTP Basic Authorization header sent by the client. When Jetty see that request, it does not send back the expected HTTP/401 with a WWW-Negotiate header. I just seem a plain HTTP/401 that comes from application (as the user was not authenticated).

Looking at the source of SpnegoAuthenticator[1], the negotiate challenge will _only_ be sent when no Authorization headed was sent by the client. This seemed a bit odd to me, so I re-read RFC-4559[2], section 4.1:

<quote>
If the server receives a request for an access-protected object, and
if an acceptable Authorization header has not been sent, the server
responds with a "401 Unauthorized" status code, and a "WWW-
Authenticate: Negotiate" header as per the framework described in [RFC2616].
</quote>

Given the above, my initial interpretation was that if a client provides some Authorization header which is not sufficient for SPNEGO authentication, SpnegoAuthenticator should sent the challenge request. That is not the case -- SpnegoAuthenticator will only send the challenge request when _no_ Authorization header is provided.

I wanted to drop a note because I can imagine that there are edge-cases which I'm not considering. Thanks in advance!


- Josh

[1] https://github.com/eclipse/jetty.project/blob/0c8273f2ca1f9bf2064cd9c4c939d2546443f759/jetty-security/src/main/java/org/eclipse/jetty/security/authentication/SpnegoAuthenticator.java#L76-L94
[2] https://tools.ietf.org/html/rfc4559
_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev


_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Missing WWW-Authenticate from SpnegoAuthenticator when other Authorization header provided

Josh Elser
Thanks for the information/reply, Joakim.

Are you implying that these RFCs answer my question about
SpnegoAuthenticator? Or maybe you just wanted to point me to updated info?

A quick skim over rfc7235 shows language equivalent to what I stated
originally:

<quote>
Upon receipt of a request for a protected resource that omits
credentials, contains invalid credentials (e.g., a bad password) or
partial credentials [...], an origin server SHOULD send a 401
(Unauthorized) response that contains a WWW-Authenticate header field
with at least one (possibly new) challenge applicable to the
requested resource.
</quote>

- Josh

On 7/27/17 5:33 PM, Joakim Erdfelt wrote:

> RFC2616 is obsolete.
>
> Replaced with many updated RFCs:
>
>   * https://tools.ietf.org/html/rfc7230
>   * https://tools.ietf.org/html/rfc7231
>   * https://tools.ietf.org/html/rfc7232
>   * https://tools.ietf.org/html/rfc7233
>   * https://tools.ietf.org/html/rfc7234
>   * https://tools.ietf.org/html/rfc7235
>
> Authorization and Proxy-Authorization headers are defined in:
>
> https://tools.ietf.org/html/rfc7231#section-5.4
> and https://tools.ietf.org/html/rfc7235
>
>
> Joakim Erdfelt / [hidden email] <mailto:[hidden email]>
>
> On Thu, Jul 27, 2017 at 1:18 PM, Josh Elser <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi all,
>
>     I've been digging into an interesting case I'd like to run by you all.
>
>     I have a Jetty application that requires SPNEGO authentication
>     sitting behind a reverse-proxy that requires HTTP Basic
>     authentication (clients use Basic auth to talk to the reverse-proxy
>     and the reverse-proxy uses SPNEGO to talk to the Jetty application).
>     The problem was that the reverse-proxy was failing to authenticate
>     with the Jetty application.
>
>     Digging further, I noticed that the reverse-proxy does not strip the
>     HTTP Basic Authorization header sent by the client. When Jetty see
>     that request, it does not send back the expected HTTP/401 with a
>     WWW-Negotiate header. I just seem a plain HTTP/401 that comes from
>     application (as the user was not authenticated).
>
>     Looking at the source of SpnegoAuthenticator[1], the negotiate
>     challenge will _only_ be sent when no Authorization headed was sent
>     by the client. This seemed a bit odd to me, so I re-read
>     RFC-4559[2], section 4.1:
>
>     <quote>
>     If the server receives a request for an access-protected object, and
>     if an acceptable Authorization header has not been sent, the server
>     responds with a "401 Unauthorized" status code, and a "WWW-
>     Authenticate: Negotiate" header as per the framework described in
>     [RFC2616].
>     </quote>
>
>     Given the above, my initial interpretation was that if a client
>     provides some Authorization header which is not sufficient for
>     SPNEGO authentication, SpnegoAuthenticator should sent the challenge
>     request. That is not the case -- SpnegoAuthenticator will only send
>     the challenge request when _no_ Authorization header is provided.
>
>     I wanted to drop a note because I can imagine that there are
>     edge-cases which I'm not considering. Thanks in advance!
>
>
>     - Josh
>
>     [1]
>     https://github.com/eclipse/jetty.project/blob/0c8273f2ca1f9bf2064cd9c4c939d2546443f759/jetty-security/src/main/java/org/eclipse/jetty/security/authentication/SpnegoAuthenticator.java#L76-L94
>     <https://github.com/eclipse/jetty.project/blob/0c8273f2ca1f9bf2064cd9c4c939d2546443f759/jetty-security/src/main/java/org/eclipse/jetty/security/authentication/SpnegoAuthenticator.java#L76-L94>
>     [2] https://tools.ietf.org/html/rfc4559
>     <https://tools.ietf.org/html/rfc4559>
>     _______________________________________________
>     jetty-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     To change your delivery options, retrieve your password, or
>     unsubscribe from this list, visit
>     https://dev.eclipse.org/mailman/listinfo/jetty-dev
>     <https://dev.eclipse.org/mailman/listinfo/jetty-dev>
>
>
>
>
> _______________________________________________
> jetty-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Missing WWW-Authenticate from SpnegoAuthenticator when other Authorization header provided

Greg Wilkins
Josh,

sounds like a bug in there somewhere, so I've opened: https://github.com/eclipse/jetty.project/issues/1698

We don't do a lot with Spnego, so it may take us a little while to get around to fixing (as most time will be setting up to test and remembering what it is all about).

We'd very much welcome a pull request if you wanted to have a go at fixing it yourself.

cheers





On 27 July 2017 at 23:41, Josh Elser <[hidden email]> wrote:
Thanks for the information/reply, Joakim.

Are you implying that these RFCs answer my question about SpnegoAuthenticator? Or maybe you just wanted to point me to updated info?

A quick skim over rfc7235 shows language equivalent to what I stated originally:

<quote>
Upon receipt of a request for a protected resource that omits
credentials, contains invalid credentials (e.g., a bad password) or
partial credentials [...], an origin server SHOULD send a 401
(Unauthorized) response that contains a WWW-Authenticate header field
with at least one (possibly new) challenge applicable to the
requested resource.
</quote>

- Josh

On 7/27/17 5:33 PM, Joakim Erdfelt wrote:
RFC2616 is obsolete.

Replaced with many updated RFCs:

  * https://tools.ietf.org/html/rfc7230
  * https://tools.ietf.org/html/rfc7231
  * https://tools.ietf.org/html/rfc7232
  * https://tools.ietf.org/html/rfc7233
  * https://tools.ietf.org/html/rfc7234
  * https://tools.ietf.org/html/rfc7235

Authorization and Proxy-Authorization headers are defined in:

https://tools.ietf.org/html/rfc7231#section-5.4
and https://tools.ietf.org/html/rfc7235


Joakim Erdfelt / [hidden email] <mailto:[hidden email]>


On Thu, Jul 27, 2017 at 1:18 PM, Josh Elser <[hidden email] <mailto:[hidden email]>> wrote:

    Hi all,

    I've been digging into an interesting case I'd like to run by you all.

    I have a Jetty application that requires SPNEGO authentication
    sitting behind a reverse-proxy that requires HTTP Basic
    authentication (clients use Basic auth to talk to the reverse-proxy
    and the reverse-proxy uses SPNEGO to talk to the Jetty application).
    The problem was that the reverse-proxy was failing to authenticate
    with the Jetty application.

    Digging further, I noticed that the reverse-proxy does not strip the
    HTTP Basic Authorization header sent by the client. When Jetty see
    that request, it does not send back the expected HTTP/401 with a
    WWW-Negotiate header. I just seem a plain HTTP/401 that comes from
    application (as the user was not authenticated).

    Looking at the source of SpnegoAuthenticator[1], the negotiate
    challenge will _only_ be sent when no Authorization headed was sent
    by the client. This seemed a bit odd to me, so I re-read
    RFC-4559[2], section 4.1:

    <quote>
    If the server receives a request for an access-protected object, and
    if an acceptable Authorization header has not been sent, the server
    responds with a "401 Unauthorized" status code, and a "WWW-
    Authenticate: Negotiate" header as per the framework described in
    [RFC2616].
    </quote>

    Given the above, my initial interpretation was that if a client
    provides some Authorization header which is not sufficient for
    SPNEGO authentication, SpnegoAuthenticator should sent the challenge
    request. That is not the case -- SpnegoAuthenticator will only send
    the challenge request when _no_ Authorization header is provided.

    I wanted to drop a note because I can imagine that there are
    edge-cases which I'm not considering. Thanks in advance!


    - Josh

    [1]
    https://github.com/eclipse/jetty.project/blob/0c8273f2ca1f9bf2064cd9c4c939d2546443f759/jetty-security/src/main/java/org/eclipse/jetty/security/authentication/SpnegoAuthenticator.java#L76-L94
    <https://github.com/eclipse/jetty.project/blob/0c8273f2ca1f9bf2064cd9c4c939d2546443f759/jetty-security/src/main/java/org/eclipse/jetty/security/authentication/SpnegoAuthenticator.java#L76-L94>
    [2] https://tools.ietf.org/html/rfc4559
    <https://tools.ietf.org/html/rfc4559>
    _______________________________________________
    jetty-dev mailing list
    [hidden email] <mailto:[hidden email]>
    To change your delivery options, retrieve your password, or
    unsubscribe from this list, visit
    https://dev.eclipse.org/mailman/listinfo/jetty-dev
    <https://dev.eclipse.org/mailman/listinfo/jetty-dev>




_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev

_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev



--

_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Missing WWW-Authenticate from SpnegoAuthenticator when other Authorization header provided

Josh Elser
That'd be great, Greg!

I'll try to get a PR ready today. I had already hacked around this downstream. Testing will be the tricky part ;)

On Jul 28, 2017 08:34, "Greg Wilkins" <[hidden email]> wrote:
Josh,

sounds like a bug in there somewhere, so I've opened: https://github.com/eclipse/jetty.project/issues/1698

We don't do a lot with Spnego, so it may take us a little while to get around to fixing (as most time will be setting up to test and remembering what it is all about).

We'd very much welcome a pull request if you wanted to have a go at fixing it yourself.

cheers





On 27 July 2017 at 23:41, Josh Elser <[hidden email]> wrote:
Thanks for the information/reply, Joakim.

Are you implying that these RFCs answer my question about SpnegoAuthenticator? Or maybe you just wanted to point me to updated info?

A quick skim over rfc7235 shows language equivalent to what I stated originally:

<quote>
Upon receipt of a request for a protected resource that omits
credentials, contains invalid credentials (e.g., a bad password) or
partial credentials [...], an origin server SHOULD send a 401
(Unauthorized) response that contains a WWW-Authenticate header field
with at least one (possibly new) challenge applicable to the
requested resource.
</quote>

- Josh

On 7/27/17 5:33 PM, Joakim Erdfelt wrote:
RFC2616 is obsolete.

Replaced with many updated RFCs:

  * https://tools.ietf.org/html/rfc7230
  * https://tools.ietf.org/html/rfc7231
  * https://tools.ietf.org/html/rfc7232
  * https://tools.ietf.org/html/rfc7233
  * https://tools.ietf.org/html/rfc7234
  * https://tools.ietf.org/html/rfc7235

Authorization and Proxy-Authorization headers are defined in:

https://tools.ietf.org/html/rfc7231#section-5.4
and https://tools.ietf.org/html/rfc7235


Joakim Erdfelt / [hidden email] <mailto:[hidden email]>


On Thu, Jul 27, 2017 at 1:18 PM, Josh Elser <[hidden email] <mailto:[hidden email]>> wrote:

    Hi all,

    I've been digging into an interesting case I'd like to run by you all.

    I have a Jetty application that requires SPNEGO authentication
    sitting behind a reverse-proxy that requires HTTP Basic
    authentication (clients use Basic auth to talk to the reverse-proxy
    and the reverse-proxy uses SPNEGO to talk to the Jetty application).
    The problem was that the reverse-proxy was failing to authenticate
    with the Jetty application.

    Digging further, I noticed that the reverse-proxy does not strip the
    HTTP Basic Authorization header sent by the client. When Jetty see
    that request, it does not send back the expected HTTP/401 with a
    WWW-Negotiate header. I just seem a plain HTTP/401 that comes from
    application (as the user was not authenticated).

    Looking at the source of SpnegoAuthenticator[1], the negotiate
    challenge will _only_ be sent when no Authorization headed was sent
    by the client. This seemed a bit odd to me, so I re-read
    RFC-4559[2], section 4.1:

    <quote>
    If the server receives a request for an access-protected object, and
    if an acceptable Authorization header has not been sent, the server
    responds with a "401 Unauthorized" status code, and a "WWW-
    Authenticate: Negotiate" header as per the framework described in
    [RFC2616].
    </quote>

    Given the above, my initial interpretation was that if a client
    provides some Authorization header which is not sufficient for
    SPNEGO authentication, SpnegoAuthenticator should sent the challenge
    request. That is not the case -- SpnegoAuthenticator will only send
    the challenge request when _no_ Authorization header is provided.

    I wanted to drop a note because I can imagine that there are
    edge-cases which I'm not considering. Thanks in advance!


    - Josh

    [1]
    https://github.com/eclipse/jetty.project/blob/0c8273f2ca1f9bf2064cd9c4c939d2546443f759/jetty-security/src/main/java/org/eclipse/jetty/security/authentication/SpnegoAuthenticator.java#L76-L94
    <https://github.com/eclipse/jetty.project/blob/0c8273f2ca1f9bf2064cd9c4c939d2546443f759/jetty-security/src/main/java/org/eclipse/jetty/security/authentication/SpnegoAuthenticator.java#L76-L94>
    [2] https://tools.ietf.org/html/rfc4559
    <https://tools.ietf.org/html/rfc4559>
    _______________________________________________
    jetty-dev mailing list
    [hidden email] <mailto:[hidden email]>
    To change your delivery options, retrieve your password, or
    unsubscribe from this list, visit
    https://dev.eclipse.org/mailman/listinfo/jetty-dev
    <https://dev.eclipse.org/mailman/listinfo/jetty-dev>




_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev

_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev



--

_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev


_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev