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...
>
> 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?
No Apache, no mod_lookup_identity. But a Tomcat Realm
implementation that does a lookup of principal info via SSSD via
D-Bus, like what mod_lookup_identity does for Apache.