On Thu, Nov 12, 2015 at 04:40:10PM +1000, Fraser Tweedale wrote: > > Just an update on my investigations of doing SPNEGO authn to > Dogtag/Tomcat and a summary of what I think I'll need to do to get > it going. > > Even for a trivial app configuring Tomcat to do SPNEGO is pretty > awful. I made some notes[1] on this and I'll turn that into a blog > post later, once I have a Realm story to go with it (I'm thinking > mod_lookup_identity for Tomcat; more on that below). > > [1] https://github.com/frasertweedale/notes-redhat/blob/master/tomcat.rst > > > The unfortunate case is that the `Authenticator' interface does not > chain, hence we already have our own `SSLAuthenticatorWithFallback' > authenticator valve implementation which we use to fall back to > Basic authentication when there is no client certificate. > > I see two general approaches to the "multiple authentication > options" problem. > > a) a "parallel deployment" in a separate <Context> where we host the > app in parallel at '/<subsystem>/spnego/...' or > '/spnego/<subsystem>/...' and use the `SpnegoAuthenticator' valve. > This is a pretty "heavyweight" approach and I believe sessions from > one do not flow to the other, and a whole separate CMS application > is running. So it does not seem viable. > > b) `SSLAuthenticatorWithFallback' becomes "SSL or SPNEGO or Basic" > valve. The problem here is that protocol-wise there is no > indication on initial request whether client can do SPNEGO or not, > so it is not clear how server should respond. An example of how > this could be resolved is the client providing a '?spnego=1' query > param; ugly but it should work, and w.r.t. REST API the client need > only do it on /rest/account/login and use their session cookie > thereafter, so I don't think it is too onerous. > > So it looks like (b) but if someone can suggest another approach I'm > listening! > > > As for the Realm, the current implementation is a bit unorthodox - > we use our own ProxyRealm class and "inject" a PKIRealm into it. > I'm not sure why this approach is needed becaues PKIRealm does not > need any configuration either on instantiation or afterwards. > > I think the best approach here would be to use CombinedRealm[2] and > add PKIRealm as well as whatever other Realms are needed. For IPA > usage I am leaning toward the mod_lookup_identity approach; given > principal name look up roles (groups) via D-Bus. > > [2] > https://tomcat.apache.org/tomcat-7.0-doc/config/realm.html#Combined_Realm_-_org.apache.catalina.realm.CombinedRealm > > Jan: does this approach make sense to you and do you know of any > projects to do this with Tomcat already?
I'm a bit confused. Do you try to do the authentication in tomcat or do you try to front-end tomcat with Apache? If you do it in tomcat itself (like the investigation seems to suggest), what is the role of mod_lookup_identity here? -- Jan Pazdziora | adelton at #ipa*, #brno Senior Principal Software Engineer, Identity Management Engineering, Red Hat _______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel