On 07/10/2015 16:33, Christopher Schultz wrote: > Mark, > > On 10/6/15 2:44 PM, Mark Thomas wrote: >> 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. > > What about an ant target to build just that JAR? It's pretty simple for > us to add, and we could just leave it in the src package. So it's one > more step for a dev to build a separate JAR (get the source package, or, > alternatively, extract the classes).
Meh. > Or we could just say "build against catalina.jar, but don't bundle it > with your web app". That works for me :). >>> 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. > > I'll have a look at doing that. I'll start with making the CH available > for a Realm since I think that will be slightly easier. Then I'll see > about making local-realms visible. I'm not sure where all of that code > is, so if someone wants to beat me to the punch, I'm happy to let them. That should be as simple as ensuring the getters are available and adding them to the MBean descriptors. Accessing the CH will mean registering the CH. Probably best to do this as part of the Realm registration. >> 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. > > Oh, that would be way better. JMX is ... awful, but it gets the job done > for remote-control and other similar use-cases. > > I think it would be really great to have > org.apache.catalina.realm.credentialHandler bound to the in-effect > credential handler for the application. Is there a good way to protect > servlet-context-scoped attributes so they can't be overwritten? o.a.catalina.core.ApplicationContext.setAttributeReadOnly(String) Mark > > Thanks, > -chris > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
