-----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.
- -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
