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-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org -- Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
