Hello Yuval.
As a kind of generic answer to your previous enquiries :
Tomcat is a "Servlet Container", and the developers who write Tomcat strive to have it
behave in accordance with the applicable "Java Servlet Specification".
Refer to this page to find out which version of Tomcat matches which version of the
Servlet Specification : http://tomcat.apache.org/whichversion.html
and then search the web for the appropriate version of the Servlet
Specifications.
As the name indicates, this document describes in detail what java servlets and servlet
containers should and should not do, and in some cases how they should do it.
In that specification, there is a chapter entitled "Security" which among other things
covers the various forms of user authentication that should be supported by any
specs-respecting servlet container and which you are encouraged to read, as it already
contains answers to many of your questions.
In summary though, there are essentially 2 sub-categories there :
- container-managed (which covers Basic, Digest and Form-based user
authentication)
- application-managed (which is whatever a developer may choose to implement at
application (webapp/servlet) level, e.g. via servlet filters)
As far as container-managed Form-based authentication is concerned, what Tomcat provides
is what the Servlet Specification says that it should.
(And that does not cover the "remember me" feature as you describe it below).
There may be third-parties which offer such enhancements (free or commercial), but you
will need to search for them.
Note that in addition to the above 3 container-managed authentication mechanisms, Tomcat
does also provide some additional options, like SPNEGO, JAAS etc..
See here : http://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html
and here : http://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html
And what Tomcat does provide is /sessions/, for which you can set yourself the expiration
time. It does not really do the same as the "remember me" feature you are talking about,
but it may cover your needs to some extent, depending on your circumstances.
Sessions are also explained in a chapter of the Servlet Specification.
HTH
Yuval Schwartz wrote:
Hello Chris,
Answers below.
Thanks again.
On Mon, May 25, 2015 at 3:18 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Yuval,
On 5/24/15 5:06 PM, Yuval Schwartz wrote:
Firstly, I'd like to clear something up: Is container managed
security security only intended for use with administrative users
of a web application?
No. What would give you that impression?
Because I was intending on using it for all users of my web
application (eg: customers, students, etc. People with no
administrative responsibilities).
You can use it with everyone.
On Sun, May 24, 2015 at 9:00 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
Yuval,
On 5/23/15 7:15 AM, Yuval Schwartz wrote:
I can currently initialize a MessageDigestCredentialHandler
object with my desired salt, iteration and algorithm
parameters and then call the handler's mutate() method before
inserting the password into my database.
Good.
And, from a servlet, the HttpServletRequest Object's login()
(for example) method works when inputting the user_name and
plain text password.
Good.
However, I am still struggling to create my database input
({salt}:{iterations}:{hash}) without inputting my desired
parameter (iterations, saltLength, etc.) to a
MessageDigestCredentialHandler, but rather by getting these
parameters (or the CredentialHandler itself) from the
servlet.
What have you tried? Do you want the remote user to be able to
specify the salt size and iterations?
I'd advise against that, since users may
intentionally reduce their own security (or, worse, intentionally
give you an effectively infinite salt or iteration count, which
could represent a DOS vulnerability).
Without being able to do this, I don't see the purpose of
specifying these parameters in the nested
<CredentialHandler> element within the <Realm> element of the
context.xml file (these parameters are retrieved from the
"storedCredential" when authenticating meaning they're not
used when a method such as request.login() is performed).
The are absolutely used when HttpServletRequest.login() is called.
That login() method ultimately calls Realm.authenticate(), which
uses the CredentialHandler. The settings in CredentialHandler
entirely handle logins for existing users.
Realm.authenticate() calls
MessageDigestCredentialHandler.matches(inputCredential,
storedCredential) calls
DigestCredentialHandlerBase.matchesSaltIterationsEncoded(inputCredent
ials,
storedCredentials) (line 146 of class MessageDigestCredentialHandler)
This method isolates the salt from the storedCredential (line
162) Then isolates the iterations from the storedCredential (line
164) Then uses both these parameters in addition to the
inputCredential to call MessageDigestCredentialHandler.mutate(
inputCredential, salt, iterations). Then does calls the equals
method of String class to compare the mutated results.
Therefore I concluded that the salt and iterations are taken from
the stored password when authenticate() is called.
Correct: both the salt and iteration could is stored in the database
along with the actual hashed credential.
Also, if I change the iterations and saltLength in my context.xml
file, authentication is still successful regardless of the values
I input.
Correct: the stored credentials still include the salt length and
iteration count. If you specify the "iterations" and "saltLength" in
context.xml, they will be applied to the CredentialHandler object, but
no code actually uses that.
Note that neither the "saltLength" nor the "iterations" attributes are
documented in the Tomcat users' guide... because they are unnecessary.
Did I configure something incorrectly?
It looks like you are struggling to create the stores credentials
in the first place (e.g. in a "change password" or "register"
workflow).
I wanted to do it by getting the same
MessageDigestCredentialHandler that I defined in the context.xml
in my servlet.
This is not possible without a great deal of work. I would just
instantiate my own MessageDigestCredentialHandler, configure it, and
then use it to create new credentials.
But since I am not able to, I just initialize a new
MessageDigestCredentialHandler and use that to create the stored
credentials.
Sounds good.
Is there any way to authenticate a user using just the stored
credential (ie: I don't have the plain text password. I only have
the storedCredential and I want to call request.login(). Is that
possible?
Tomcat can't authenticate without the plain-text credential. That's
whe whole point of authentication: to prove that the remote client is
who they say they are. Without the plain-text credential, there's
nothing to verify.
What are you actually trying to do, here... it sounds like you don't
want to do standard username/password authentication.
I want to do standard username/password authentication.
However, I also want an additional (common) feature that a lot of other
websites have: a "remember me" checkbox.
This "remember me" checkbox will store a cookie with a unique id in it.
My database will link this unqiue id to the userid.
Then I can retrieve the user object in the servlet.
Then I would like to log him in with request.login(). However, at this
point, all I have is the hashed version of the password (because it was
retrieved from my database, not from the user).
How else can I go about doing this?
Thanks.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVYxMYAAoJEBzwKT+lPKRYrTUQAJEBT6IXUIbnFJlBTxPIBDia
SqTh2YfWom5c2a+M6A3354llz6jnW8LZNU+In2sXgC9kwae3FwHLiPsUNEV+HWAq
674gKOvwNm2j7Ic5NwZe03tmzhFIpA3hz+Rr4oriAb38VeMpvpWjqZFGu1x8fEJi
+RJO6g8W85Lg9enkeoPxyA3bBdPuE+WtD2gGPcbZsrgh4g/V9HSNq0Wp7rlv9eez
kOnP2hOip/+wDVJ/9j3OObXK/F6ZFHZtZHlJbI9W15qm6FsPhY1F0XLMhWQUrXCi
Ifmw4Ljwle078EV6NxfLRZyC88Ap45y70Y9a6JX/K9jZFTwhQZpxKiwE3wftPY+d
aXBiMUd/imSOOmkGIYsQSNyFTqwwsi30/ZxY5LyvYKUKCNFsczpG2LrUGF9/ItqF
DdS0hR9Rbyz+9uiTFgAjG1fcvVSnTcCS4CfuQTDa1wdMYz+B4y39ewdq8gkej4SF
XxKkYGtphIx4zxtG7ud3TtoGsew8bxMI8q363NRvjKBxVlhE4uAPibUE03eY6Qhi
pGo26GMva/FjYLm7rhJBng+qNuiETYi2NXIGgUpXGyAxHRW/f1rU/AcelEUp8sx2
T9SjCcf67Bpthh92b8ihmCdZS4MZkdNclv6gvFTFBE84uRsefgs8fYsY/G0NeWPJ
fmZnh9WI0zRote025Vnh
=Cf7r
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
