Mixing Two-Factor with Federation
We currently have a SAML 2.0 infrastructure using PicketLink Federation 2.1.7, running on JBoss AS7.2. We have several SP applications tied in, including PicketLink enabled Java web applications, .NET applications, and even a ColdFusion application. To date, this has served us well, and we are quite pleased with the PicketLink implementation.
We now have a requirement to add two-factor authentication to this environment, I had investigated this last year, and while I succeeded in producing a working prototype, there were several parts that left me less than thrilled with the approach. I am hoping things have evolved since that point, and that someone can direct me to appropriate solutions. My goal is to be able to support two-factor authentication at the IDP, and to do so in a way that leverages standard extension points of the PicketLink subsystem, such that the whole solution can evolve alongside PicketLink, rather than effectively being a fork of the code because it has to replace elements which are not meant to be configurable.
There are a couple of specific areas where I am stuck. The first is with integrating Two Factor into the IDP application. In the Two Factor example in the PicketLink quickstarts, the second factor is authenticated in application code, inside the container. However, in the case of Federation, we never actually reach the application code, because if the user is authenticated via the LoginModules, the Federation implementation kicks in and issues the SAML response and redirects the user away before they get through to the actual application. This means the second factor needs to be added as a LoginModule, in order to work properly with the Federation, which brings me to the second issue.
Implementing a LoginModule that authenticates a second factor is problematic, because the implementation of the Realm that is provided only knows how to handle Password and Certificate credentials, and refuses to deal with any others. While I could extend the Realm, there appears not to be a way to specify the Realm class used in the configuration. Within Tomcat, this is part of the server.xml, but the web subsytem that wraps the web container appears not to expose this configuration in any way, meaning we're locked to the default implementation.
The next step was to implement a full JASPI authenticator replacement, bypassing the Realm entirely, and do the authentication of both steps directly. This works, but it has several disadvantages, including the fact that it precludes me from leveraging existing LoginModules for things like LDAP-based authentication. This means I'm not actually using most of the PicketLink security mechanisms, and only leveraging it for the SAML workflow. This also implies that future features won't be available to me without even greater work.
Has anyone else attempted to provide Two Factor Authentication at the IDP for SAML-based federation? Is there some part of the API I'm missing, or is this a shortcoming of the overall stack? Upgrading, including upgrading the entire server to a newer version, or even EAP, is not out of the question for us, but I need to know that it will actually resolve this problem.
Alternately, I'd be happy to implement some of this as a contributor so that it goes in to the PicketLink code stream, if I can work with the correct people to ensure I'm not going down a path that's not in line with other efforts. Either way, some amount of direction and/or coordination seems necessary.
PS - In my original investigation, I started a thread here looking for direction, but never managed to get any responses, even as I worked through things. It contains more details on some of the steps as I went, and might be a useful reference: Multi-factor on the IDP