tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ludovic Pénet <>
Subject Re: Password Authentication Lib?
Date Sun, 01 Jan 2017 09:26:42 GMT

I have a question relating to your thread (at least in my mind) : is there a standard, easy
way to reread roles for an authenticated user ?

The use case is as follow : I implement JSON web tokens (JWT) as a valve, generating it after
the container performed authentication and restoring principal when a valid token is passed.

I also use JWT as poor man SSO accross systems. But roles are not the same. I would like to
be able to read roles sometimes.

Thanks in advance,

Le 1 janvier 2017 08:07:09 GMT+01:00, Christopher Schultz <>
a écrit :
>Hash: SHA256
>On 12/31/16 2:30 PM, Roger Marquis wrote:
>>>> Do we also need to derive the algorithm, saltLength and
>>>> iterations from server.xml?
>>> Nope. If you follow what's in that presentation starting on slide
>>> 29,
>> This is the design element that isn't clear. Since the stored hash
>> will constant across 99% of use cases, if not 100%, usability
>> measures indicate it should be an optional default?  It's also odd
>> considering the method doesn't require a dev to derive any other
>> hash elements.
>I'm not sure what you mean, here. You're right, once set, a set of
>parameters (e.g. salt length = 64 bits, iteration count=10k), they
>aren't likely to change for a while. But the encapsulation of
>everything into the CredentialHandler implementation means that you
>can adjust those parameters upward (e.g. salt length=128 bits,
>iteration count=100k) in the future without having to change any code
>at all.
>You can even change from salted-iteration over to PBKDF2 or bcrypt or
>whatever trivially by changing the CH configuration to use a set of
>nested CredentialHandlers:
><CredentialHandler type="combined"> (paraphrasing)
>  <CredentialHandler type="pbkdf2" /> (the new scheme)
>  <CredentialHandler type="sha256" /> (the old scheme)
>No code needs to change and you can switch algorithms.
>>> You could easily write your own CredentialHandler
>> That would be easy enough but also likely to require more
>> refactoring across subsequent Tomcat releases.  Minimizing
>> maintenance is one of the main reasons we prefer Tomcat (and Java)
>> to other http backends.
>Understood. The introduction of the CredentialHandler interface was
>done precisely because it was awkward to do anything similar with
>previous versions. You can never really divorce this kind of thing
>from the container entirely.
>What you can do is write a custom CredentialHandler and package it in
>a separate JAR file that is independent from your application (but
>semi-dependent upon the Tomcat version).
>For the most part, the built-in CredentialHandler implementations
>should meet the needs of most environments, but new ones can be
>written and plugged-in should the need arise.
>And, of course, the application can get a reference to the configured
>CH for an application and use it, either for verification of an
>existing password or for mutating a new one (e.g. for "change
>password" operations).
>- -chris
>Comment: GPGTools -
>Comment: Using GnuPG with Thunderbird -
>To unsubscribe, e-mail:
>For additional commands, e-mail:

Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message