9:32 a.m.
On 11/12/2015 12:40 AM, Fraser Tweedale wrote:
Hi all,
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.
This would be the cleanest approach since the client will only talk to
the web application that supports the same authentication. So IPA and
Barbican will be talking to /ipa/kra and /barbican/kra that is
configured with SPNEGO, and CA will be talking to /pki/kra that is
configured with basic/client cert authentication.
As you know the issue is currently we do not support multiple PKI
subsystems of the same type running on the same Tomcat instance, and
adding that support is a huge task.
However, there might be a relatively simpler alternative. The PKI
subsystems probably can be moved out of the web application
(WEB-INF/lib) into the Tomcat server itself (common/lib). The web
applications will remain exists, but it's only used as a façade to the
PKI subsystems running in the background. This way a single PKI
subsystem can have multiple web applications customized for different
clients.
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!
The issue with (b) is it's mixing the users, groups, authenticators,
realms, and subsystem-specific objects such as KRA secrets for different
clients (IPA, Barbican, and PKI itself) into a single pool, plus the
ugly URL (your word, not mine :) ).
If the option (a) is doable within the timeframe I'd rather pick that
one. It can avoid a number of problems and solve other issues as well.
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.
The ProxyRealm is needed to resolve class dependency issue (which can be
solved with option (a)):
http://pki.fedoraproject.org/wiki/Authentication
Tomcat requires that the classes for the authenticator and the realm
must be stored in common/lib. The problem is the PKI classes that do the
authentication are stored in the WEB-INF/lib, which is not accessible
directly by the realm. To address this problem, a ProxyRealm is created
in common/lib to satisfy Tomcat's requirement and a PKIRealm is created
in WEB-INF/lib to execute the actual authentication. When the Web
application is started, the ProxyRealm will be linked to the PKIRealm
(see CMSStartServlet.java below). The ProxyRealm will then forward any
incoming authentication request to the PKIRealm.
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.
The CombinedRealm will not be needed with option (a).
[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?
Ade: what sort of behaviour do you need in the Realm for the Barbian
use case?
Any and all feedback welcome.
Thanks,
Fraser
--
Endi S. Dewata