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. 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? Ade: what sort of behaviour do you need in the Realm for the Barbian use case? Any and all feedback welcome. Thanks, Fraser
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? -- Jan Pazdziora | adelton at #ipa*, #brno Senior Principal Software Engineer, Identity Management Engineering, Red Hat
On Thu, Nov 12, 2015 at 08:34:11AM +0100, Jan Pazdziora wrote:
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.
On Thu, Nov 12, 2015 at 07:46:25PM +1000, Fraser Tweedale wrote:
On Thu, Nov 12, 2015 at 08:34:11AM +0100, Jan Pazdziora wrote:
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.
In general, that is what we tell people not to do. The goal is to use external authenticatication and identity operations in frontend server (Apache) and applications / frameworks consuming the results. The benefit of this approach is that you don't have to reimplement things when you say want to support additional protocol -- hopefully, the platform will do it for you in the form of Apache modules. The mod_auth_openidc is a prime example -- ideally, any application that consumes results of external authentication (which was initially done for example to support Kerberos) gets OpenId Connect for free, just by reconfiguring the frontend Apache HTTP Server. -- Jan Pazdziora | adelton at #ipa*, #brno Senior Principal Software Engineer, Identity Management Engineering, Red Hat
On Thu, Nov 12, 2015 at 11:20:10AM +0100, Jan Pazdziora wrote:
On Thu, Nov 12, 2015 at 07:46:25PM +1000, Fraser Tweedale wrote:
On Thu, Nov 12, 2015 at 08:34:11AM +0100, Jan Pazdziora wrote:
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.
In general, that is what we tell people not to do.
The goal is to use external authenticatication and identity operations in frontend server (Apache) and applications / frameworks consuming the results. The benefit of this approach is that you don't have to reimplement things when you say want to support additional protocol -- hopefully, the platform will do it for you in the form of Apache modules. The mod_auth_openidc is a prime example -- ideally, any application that consumes results of external authentication (which was initially done for example to support Kerberos) gets OpenId Connect for free, just by reconfiguring the frontend Apache HTTP Server.
In this case I would be implementing a Realm module for Tomcat as an application server (Dogtag to consume the resulting information in our case). It does not always make sense to put Apache in front of Tomcat, and we cannot assume such a setup. The similar argument exists for Nginx; for which a "lookup identity" module was also implemented. I was wondering if you (or others) were aware of any existing implementation for Tomcat. Cheers, Fraser
-- Jan Pazdziora | adelton at #ipa*, #brno Senior Principal Software Engineer, Identity Management Engineering, Red Hat
On Thu, Nov 12, 2015 at 09:26:19PM +1000, Fraser Tweedale wrote:
I was wondering if you (or others) were aware of any existing implementation for Tomcat.
I'm not. -- Jan Pazdziora | adelton at #ipa*, #brno Senior Principal Software Engineer, Identity Management Engineering, Red Hat
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
participants (3)
-
Endi Sukma Dewata -
Fraser Tweedale -
Jan Pazdziora