[Pki-devel] SPNEGO for Dogtag

[Jan Pazdziora]

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