Am 13.01.16 um 15:48 schrieb Christopher Schultz:
Thomas,
On 1/13/16 8:31 AM, Thomas Scheffler wrote:
Am 12.01.16 um 13:24 schrieb Mark Thomas:
On 12/01/2016 11:06, Thomas Scheffler wrote:
Am 11.01.16 um 22:05 schrieb Mark Thomas:
<Valve
className="org.apache.catalina.authenticator.BasicAuthenticator"
changeSessionIdOnAuthentication="false" />
Found on
http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection
the description how to switch the "feature" off.
I will file two bugs soon describing the issues I had. Hopefully they
will be fixed.
1.) if using HttpServetRequest.login(String, String) further
request in
the session are loosing the users Principal.
2.) After changing sessionId, old sessionIds should still be valid
for a
short period of time of to the same client.
The second request will get closed as INVALID on security grounds. If
the old ID is valid for any period of time it makes a session fixation
attack possible. You might as well disable changing the session ID on
authentication.
For the first the description above isn't clear enough to be sure
exactly what you are asking for. However, based on the second request
and what I have read of this thread I suspect that request will get
closed as INVALID or WONTFIX.
Hi Mark,
if you choose to use login() and this modifies the session ID. Further
calls to login() should either:
1.) are not required as every request belonging to the same session are
already authenticated. After login() other request of the same session
will not return 'null' on getRemoteUser() or getUserPrincipal()
2.) are not required, as authenticate() use the information provided by
the first login() call.
3.) do not modify the session ID as the same user was authenticated
before and the session is therefor safe to session fixation attacks
Those 3 all boil down to essentially the same requirement.
Requests are populated with cached authentication information from the
session at the start of the request (if the authenticator is configured
to do so - all but DIGEST are by default).
Hi,
"all but DIGEST are by default" was my case.
As I walked through the code I found most of the features I requested
are already in place. There is already the tracking of the Principal in
the session. To use the values of login() later in authenticate() in
Tomcat 8.0.30 I had to insert "/foo" as my login page and "/bar" as my
login-error-page. I think any value will do here ;-)
<login-config>
<auth-method>FORM</auth-method>
<realm-name>Restricted</realm-name>
<form-login-config>
<form-login-page>/foo</form-login-page>
<form-error-page>/bar</form-error-page>
</form-login-config>
</login-config>
This activates the FormAuthenticator which correctly does, what I was
hoping for.
I think every authenticator can/should use the information stored by
login() if it is available.
Which argument to login() carries the server-generated nonce used for
login? Which argument includes the realm name?
https://en.wikipedia.org/wiki/Digest_access_authentication
Hi Chris,
the login() method gets the username and the password. It has nothing to
do with configured auth-method in the web.xml. Tomcat uses a generic
method[1] located in a super class do perform the login. The Principal
is stored in the session, if caching is enabled and a session is present
or created.
Depending on the configured auth-method the Principal is used later, if
found or not. My suggestion was to always use it, when it is stored in
the session.
Hope this clarifies my summary.
Thomas
[1] org.apache.catalina.authenticator.AuthenticatorBase.doLogin(Request,
String, String)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
