-----Ursprüngliche Nachricht-----
Von: André Warnier (tomcat) [mailto:***@ice-sa.com]
Gesendet: Mittwoch, 28. Oktober 2015 20:42
An: ***@tomcat.apache.org
Betreff: Re: AW: AW: Suppress or replace WWW-Authorization header
Post by Torsten Rieger-----Ursprüngliche Nachricht-----
Gesendet: Mittwoch, 28. Oktober 2015 16:45
Betreff: Re: AW: Suppress or replace WWW-Authorization header
You can choose between a pop-up or an HTML FORM
<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>
Post by Torsten Rieger-----Ursprüngliche Nachricht-----
Gesendet: Mittwoch, 28. Oktober 2015 15:39
Betreff: Re: AW: Suppress or replace WWW-Authorization header
Torsten,
Post by Torsten RiegerI 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
---------------------------------------------------------------------
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
deployment fails). But that's not a solution because the rest-service
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)
Post by Torsten RiegerPost by Torsten RiegerUsing 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-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org
FORM-based is not possible because of the legacy client, which only supports
BASIC-auth.
You are right, it's a problem all servers... imho it's a problem of that old
standard from the 90th, because there was no real logic on client side:
Let's have a look at the informations:
1) 401 -> Unauthorized
2) WWW-Authenticate: BASIC realm="xyz" --> Method
But that should be only interpreted as: "please send your username/password
as 'BASIC 4324CAF323=='" and NOT as "show an ugly dialog". There is no
chance to use auth with 'BASIC ...' but with an custom dialog.
That the clients can send their credentials in a BASIC compatible style is a
hard requirement. Because just one auth-method is allows for an application
in an web.xml and that must be BASIC because of the legacy client. ... but
that client doesn't matter if there is a BASIC challenge send by the server.
;-)
All solutions on application level (client or server side) will not work,
because 401-response and the processing which is leading on the client side
are handled by container and browser without a chance to modify anything by
custom code. The only way is to remove security constraints and to handle it
in my own code but without authentication capabilities from container level
except I use request.login (Servlet 3.0 API) which delegates up to
container-level from application code.
BUT I use the equinoxbridge.jar to forward all requests from the outer
container to an inner OSGi-based cxf server, and it seems that this bridge
makes everything more complicated... that .login() didn't work for me, I
think doesn't reach the outer container. :-/
If I had an normal jersey application, I could use a ContainerResponseFilter
to modify 401-errors, but that doesn't work with that equinoxbrigde because
it's a normal servlet without support for such filters... and the inner
application after that bridge is not reached if credentials are wrong.
I still thought "removing that BASIC in the WWW-authenticate header will be
a best fitting solution" ... that seems to be best practice
(https://github.com/gbif/registry/blob/master/registry-ws/src/main/java/org/gbif/registry/ws/filter/AuthResponseCodeOverwriteFilter.java)
and in the standard: challenged auth-method in the response must not be the
same as send before by the client.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org