You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2017/01/01 07:07:09 UTC
Re: Password Authentication Lib?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Roger,
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)
</CredentialHandler>
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
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYaKqdAAoJEBzwKT+lPKRY1HoQAIkJM3zWOkkw+J+0Cd7KFDgf
YevIcrHZyb6NXfyMZ4vW4DsscoYZvXA6xFaicPqvhkpLugvDV9EnFVxrXZZOwCJL
a3Ni13npKD6oBMLWfg+HmuTsg9VhCDZBzz5139LccyNyUUTo5Hww04b/ffKqjl1M
ZWoxn63xWXLOSY2BpbNr8AyzYV3nE5MXURFM7U/mauQcYdf4ZOIlOlSti8ireGm6
iYgPIbHgJ7S0xNWdg3jP/AWrYY7yYos7tM/H6ZlqvfgBAuoyvUCNkgSi0zI7geB8
Ad4EQ4x0J2rfKqTPlWZenuwI/LAeq2jhZr606tTXg62jAajtIr103LLqJfN3C83U
kbKLeS1U/Qn7o6tvJVvTmwFIt65T3HDXn8N5/1msIbZFVh14MOS9wEpWAVv5wjBb
25yb244DzchOf4PntwifqvvyFEcR+EKriMM7IGSKkqr/97RVA9fw91Kbg48eetfF
+jI6QKcMNaTcOg9OHewXIAfLlNFwZeLbkWnief0ekU5PrxEEEk30+u01sYY4Xn5F
I6FMP1lkS8O1GMglSBQRmr9e7ELlqvmH3IdHjNkxcfcju18iaa4KCPz74C5eECJc
4vRp80ogCbrDr8OqpgaZZ/RkF/BLEDhAh+8VTsGhBcF4oIWHQ8bDtU+Ann2ZqauR
Uxo76eLV2Xmo9w9Hihcs
=KpQ+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Password Authentication Lib?
Posted by Ludovic Pénet <l....@senat.fr>.
Hi.
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 <ch...@christopherschultz.net> a �crit :
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>Roger,
>
>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)
></CredentialHandler>
>
>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
>-----BEGIN PGP SIGNATURE-----
>Comment: GPGTools - http://gpgtools.org
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iQIcBAEBCAAGBQJYaKqdAAoJEBzwKT+lPKRY1HoQAIkJM3zWOkkw+J+0Cd7KFDgf
>YevIcrHZyb6NXfyMZ4vW4DsscoYZvXA6xFaicPqvhkpLugvDV9EnFVxrXZZOwCJL
>a3Ni13npKD6oBMLWfg+HmuTsg9VhCDZBzz5139LccyNyUUTo5Hww04b/ffKqjl1M
>ZWoxn63xWXLOSY2BpbNr8AyzYV3nE5MXURFM7U/mauQcYdf4ZOIlOlSti8ireGm6
>iYgPIbHgJ7S0xNWdg3jP/AWrYY7yYos7tM/H6ZlqvfgBAuoyvUCNkgSi0zI7geB8
>Ad4EQ4x0J2rfKqTPlWZenuwI/LAeq2jhZr606tTXg62jAajtIr103LLqJfN3C83U
>kbKLeS1U/Qn7o6tvJVvTmwFIt65T3HDXn8N5/1msIbZFVh14MOS9wEpWAVv5wjBb
>25yb244DzchOf4PntwifqvvyFEcR+EKriMM7IGSKkqr/97RVA9fw91Kbg48eetfF
>+jI6QKcMNaTcOg9OHewXIAfLlNFwZeLbkWnief0ekU5PrxEEEk30+u01sYY4Xn5F
>I6FMP1lkS8O1GMglSBQRmr9e7ELlqvmH3IdHjNkxcfcju18iaa4KCPz74C5eECJc
>4vRp80ogCbrDr8OqpgaZZ/RkF/BLEDhAh+8VTsGhBcF4oIWHQ8bDtU+Ann2ZqauR
>Uxo76eLV2Xmo9w9Hihcs
>=KpQ+
>-----END PGP SIGNATURE-----
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
--
Envoy� de mon appareil Android avec K-9 Mail. Veuillez excuser ma bri�vet�.