tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier (tomcat) ...@ice-sa.com>
Subject Re: AW: AW: Suppress or replace WWW-Authorization header
Date Wed, 28 Oct 2015 19:41:30 GMT
On 28.10.2015 17:42, Torsten Rieger wrote:
> -----Ursprüngliche Nachricht-----
> Von: Aurélien Terrestris [mailto:aterrestris@gmail.com]
> Gesendet: Mittwoch, 28. Oktober 2015 16:45
> An: Tomcat Users List <users@tomcat.apache.org>
> Betreff: Re: AW: Suppress or replace WWW-Authorization header
>
> You can choose between a pop-up or an HTML FORM
>
> This one looks like this in web.xml :
>
>    <login-config>
>      <auth-method>FORM</auth-method>
>      <realm-name>webapp global realm</realm-name>
>      <form-login-config>
>        <form-login-page>/login.jsp</form-login-page>
>        <form-error-page>/error_login.jsp</form-error-page>
>      </form-login-config>
>    </login-config>
>
>
>
>
> 2015-10-28 16:28 GMT+01:00 Torsten Rieger <torsten.rieger@promatis.de>:
>
>> -----Ursprüngliche Nachricht-----
>> Von: Christopher Schultz [mailto:chris@christopherschultz.net]
>> Gesendet: Mittwoch, 28. Oktober 2015 15:39
>> An: Tomcat Users List <users@tomcat.apache.org>
>> Betreff: Re: AW: Suppress or replace WWW-Authorization header
>>
>> Torsten,
>>
>> On 10/28/15 8:19 AM, Torsten Rieger wrote:
>>> I have a legacy java-SOAP-client that only supports BASIC
>>> authentication (send the Authorization: Basic... header) and a
>>> AngularJS application that consumes a REST-service (also sending the
>>> Authorization: Basic header).
>>>
>>> The server supports two kinds of deployment: Standalone with an
>>> embedded Jetty-server and as war-file for app-servers (most of them
>>> are tomcat-server). I try to suppress the browser BASIC-login-dialog
>>> for the REST-service-calls from AngularJS.
>>> On Jetty I modify the 401-responses and replace the "WWW-Authenticate"
>>> header by anything else than "BASIC" and that works, now I try to
>>> find a solution for the deployment on tomcat servers.
>>>
>>> Rewrite (unset header in responses) with an apache proxy in front of
>>> the tomcat is unfortunately not a solution I can implement.
>>>
>>> So I'm looking for a solution to remove or modify the headers in 401
>>> responses on application server level.
>>
>> So you just want to disable HTTP BASIC authentication? Why not just
>> remove the <auth-method> from web.xml and disable authentication entirely?
>>
>> Are you saying that when you connect using a REST client, the client
>> shows a login dialog in a web browser? That sounds ... weird. The REST
>> client should see the WWW-Authenticate header and either (a) fail or
>> (b) re-try with credentials you have provided to it.
>>
>> -chris
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>> No, container BASIC authentication should be enabled, the container
>> should handle the authentication, but the browser should not show his
>> ugly default login dialog when I request resources from the
>> REST-service with wrong credentials.
>> When the REST-client (web-application in the browser) receives a
>> failed login with a WWW-Authenticate header, the default dialog of the
>> browser will be shown... that’s what I want to suppress.
>>
>> When I remove the (a) <login-config> or (b) <auth-method>  sending
>> requests with credentials will not work anymore (a: 403 forbidden; b:
>> deployment fails). But that's not a solution because the rest-service
>> should be still protected and I need to authenticate via "Authentication:
>> Basic ....."
>> header send credentials, but I don't want to show the ugly
>> browser-dialog to the users.
>>
>> Using a AngularJS Client with REST-services based on tomcat should be
>> a common use-case, it could not be that I'm the first one who wants a
>> custom login-screen. :-/
>>
>> -torsten
>>
>
>
> The Problem is then, that login via "Authorization: BASIC xyz==" will not
> work anymore... the legacy client is not able to handle FORM based login :-/
>

Torsten, let me try again another way :

1)
 >> Using a AngularJS Client with REST-services based on tomcat should be
 >> a common use-case, it could not be that I'm the first one who wants a
 >> custom login-screen. :-/

No, you probably are not.  But *this has nothing to do with Tomcat per se*.
Any other webserver, in the same circumstances, would send a 401 back, with a request for

HTTP Basic authentication.
If, at the server level, you configure that for this application, you want HTTP Basic 
authentication, then that is what you will get.  It is not a choice of the server, it is 
something *imposed* by the HTTP protocol.

If you want something else to happen, but still have the client be authenticated for that

application, then you have to change the authentication method required, at the server 
level.  No way around it.

2) If the browser receives a 401 response header which indicates that the requested 
authentication method should be HTTP Basic, then it will popup its bultin HTTP Basic 
authentication popup dialog.  There is no easy way around this either, because this 
behaviour is built-in into the code of all major browsers.
(Also because the HTTP protocol says that this is what the browser should do).
If you want this to be different, then you have to find a way to modify the browser-side 
logic, so that it does not do that.  Doing this is possible, but not easy (see some of the

other responses), and if not done correctly, it will be buggy and/or introduce security 
issues.

3) all the responses which I have seen so far on this thread, are technically correct 
considering the information which you have provided as to what you would like, and what 
your client-side application can/cannot do.
But maybe here, we were all seeing the tree that you put in front of us, and for that 
reason not seeing the forest behind it.

4) Setting the server-side to do authentication in a different way than HTTP Basic, does 
not necessarily mean that your application cannot, overall, be authenticated.

The REST application on the server, presumably, does not care *how* the user is 
authenticated.  It just wants an authenticated user, no matter how that happens.
It gets the user-id from Tomcat (via request.getUser() or similar), *after* Tomcat has 
taken care of the authentication.  The way in which Tomcat obtains this user-id is not the

concern of the application. (At least, that is what a well-behaved application would do).

5) So let's do the authentication in another way, so that the client never even sees a 401

response from the server, and thus never pops up this dialog that you do not want to see.

At the server level, use the form-based authentication, like another poster here already 
suggested.
What would happen then is as follows :

a) the browser sends a first request to the REST app, un-authenticated.
b) the server sees that this is not authenticated, and sends back to the browser, a login

form.  Note that this is just a html page, that has nothing to do with the client-side 
application. (Note : you create this login form, and save it on the server.
You just need to tell the server (in the web.xml of the REST application) where this login

form is.)
c) the human client fills-in the login form, and his browser posts it back to the server.
This goes to another URL on the server (e.g. "/login"), that is *not* the REST application.
d) on the server, the login application at "/login" authenticates the user and creates a 
session, where this authenticated user-id is stored. It also sets the authenticated 
user-id in the Tomcat request structure, for later usage.
The login application also prepares a "session-id" cookie, to be sent back to the browser

(later), which points to this saved session on the server.
e) The login application now redirects the browser, to the original URL that it was 
requesting, before all this authentication stuff took place.
That is the REST application.
f) now the REST application gets called, and it can retrieve the user-id from Tomcat, as 
promised.  So it does its work, and sends back the response to the browser.
(Notice that there has never been a 401 response so far)
g) the browser gets the 1st response from the REST application. It also gets, at the same

time, the session-id cookie that was added by the authentication part.
h) if the browser now sends a second request to the REST application, this session-id 
cookie will be re-sent to the server also.
i) the server now gets the new request, and the cookie.  The server uses the cookie to 
retrieve the saved session, including the user-id in it.  The server uses this to set the

internal Tomcat user-id, and calls the REST application again.
j) the REST application starts working, and retrieves the user-id from Tomcat. So it is 
happy, and sends back the next response.
Tomcat takes care that with this next response, the session-id cookie header is sent again

to the browser.
k) the browser sends another request to the server. Go to (h) above.

Notice : still no 401 Basic response header anywhere, so no browser-side Basic auth popup.
Notice also : the client-side application is never really involved in the authentication.

So whatever it supports or not, is not relevant here.

Note that all the above supposes that the client application on the browser side, does not

need to know that it is authenticated.  But that is normally the case for client-side 
applications.

Last note : in the a-k explanation above, I have taken some liberties with the intimate 
details of how things happen on the server. I hope that the purists will forgive this bit

of poetic and tutorial license. Hopefully, it should allow Torsten to get going along the

right track, instead of pursuing mirages.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message