On 06/10/2015 18:05, Christopher Schultz wrote: > All, > > We (somewhat) recently introduced the CredentialHandler to Tomcat in > order to make it easier to use different password-munging strategies > along with all the Realm implementations. A good example is using a hash > like SHA-256 in one case (using MessageDigest) and using PBKDF2 in > another case (using SecreyKey, etc.). In the past, we had been limited > to whatever the MessageDigest class could support, and we have a nice, > flexible system, now. > > This is great for authentication against data already stored somewhere > e.g. a relational database. But it currently does not have an obviously > usable component for an application. > > Yes, you can drop catalina.jar into your application's lib directory and > then you can do this: > > SecretKeyCredentialHandler ch = new SecretKeyCredentialHandler(); > > ch.setAlgorithm(ALGORITHM); > ch.setIterations(ITERATIONS); > ch.setSaltLength(SALT_LENGTH);; > ch.setKeyLength(KEY_LENGTH); > > hashedPassword = ch.mutate(user.getPassword()); > > ... but there are two downsides to this: > > 1. The whole of catalina.jar is included in your application, possibly > breaking a great many things > 2. You have to make sure that all of the values match whatever you have > configured in your <CredentialHandler> element in context.xml > (or server.xml) > > To solve the first problem, I'm wondering if we could produce an > artifact during the build that just contains the interfaces, etc. for > the CredentialHandlers. This would allow users to build against them and > even lazily deploy them with their code.
It doesn't look to be that easy to extract the relevant classes and their dependencies into a separate JAR. If folks want to interact with the Tomcat internals I don't think it is unreasonable to expect them to compile against the standard JARs. > For the second issue, I don't see any opportunities at present. > > It doesn't look like the application's Realms are available via JMX if > they are declared local to the application -- only the global Realms are > represented by MBeans. Also, it doesn't look like the Realms offer > access to the CredentialHandlers even if they were available. > > I think these are two oversights that ought to be corrected: local > Realms ought to be locatable via JMX just as local DataSources are > available in e.g. > Catalina:type=DataSource,host=[host],context=/[context-path],class=javax.sql.DataSource,name="[name]" > and also Realms ought to expose information about their CredentialHandlers. +1. > If those are available, then applications can simply grab the same > CredentialHandler that Tomcat is using for authentication and use it for > two obvious use-cases I can think of: > > 1. Preparing new credentials for saving to the user data store (e.g. > registration, change-password, etc.) > 2. Verifying existing credentials without Tomcat performing > authentication (e.g. check-password required to update account > info, inspect password history to prohibit repeats, etc.) > > The only caveat is that the application definitely would not be able to > deploy either catalina.jar or catalina-only-credential-handlers.jar, > otherwise they'll get ClassCastExceptions when they try to use them. But > that's okay: documentation can take care of that to some degree. > > Does anyone have any thoughts on any of those items? I'd really like for > applications to be able to re-use those components if possible. Big +1 to the JMX. No so sure about the separate JAR. How about a Realm option to expose the CredentialHandler via a customer ServletContext attribute? That way users wouldn't have to jump through JMX hoops including knowing the container names. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
