3 Replies Latest reply on Aug 22, 2014 1:46 PM by Tim Kutz

    Multi-factor on the IDP

    Tim Kutz Newbie

      We are currently running a SAML-based SSO infrastructure using PicketLink 2.1.6, under JBoss 7.2.0. I've been tasked with augmenting the infrastructure to provide second factor authentication support, using Entrust to manage additional authentication credentials.  I expected to be able to implement a JAAS LoginModule which would handle the second factor, but it appears that the CallbackHandler implementation only provides the username and password credentials.  Digging further, it appears that I could get around this by implementing a custom Realm implementation, but there does not appear to be a way to replace the Realm used for a security domain.  In Tomcat, the Realm class can be configured within the server.xml, but this option does not appear to be exposed under JBoss 7.


      If I am understanding correctly, in order to collect an additional security credential from the user, I need to implement an Authenticator which will forward them to the correct page.  The Authenticator then delegates to the Realm by means of the realm.authenticate() method, but the signature on this is (username, credential).  Although I can feasibly override this, I can't get the new Realm implementation into use.


      Ultimately, what I need, is to be able to provide arbitrary credentials from the Authenticator class, to the LoginModule.  The Realm stands between the two, and manages the CallbackHandler that is in use, which would provide the final step in the bridge.  It seems the most general purpose approach would be to provide the catalina Request object directly to the CallbackHandler, and then be able to look up any arbitrary property set in the request (or session).  Without the ability to replace the Realm, though, it doesn't seem possible to provide any object to the CallbackHandler.


      Am I going about this the wrong way, or did I miss some location where the Realm class can be specified?


      Tim Kutz

        • 1. Re: Multi-factor on the IDP
          Tim Kutz Newbie

          I saw in another thread (Re: Possible to access HTTPServletResponse from LoginModule?) that someone had approached this using a ThreadLocal in the JASPI authenticator, but this then means you're effectively abandoning the CallbackHandler as an abstraction around your JAAS modules, and they instead rely on the ThreadLocal itself.  We're also a little uncomfortable with using a ThreadLocal in this way, since it seems relatively easy for a small error that fails to clean up the TheadLocal properly to result in both a memory leak, and a potentially exploitable security flaw.


          This seems like a pretty significant oversight, to not be able to plug in additional credential values for the CallbackHandler to service.  Is nobody able to provide any more guidance?


          I'm starting to look at doing all the authentication work in the JASPI layer directly, either by not using JAAS at all, or by having the Authenticator manage it's own JAAS context independent of those configured in the server.  This seems plausible, but it makes me uncomfortable to have to re-implement so much of what is already built out.


          Surely there's a better way to approach this?

          • 2. Re: Multi-factor on the IDP
            Tim Kutz Newbie

            I now have a working prototype that performs a simple two-factor authentication via a JASPI Authenticator.  In doing so, however, I am not able to leverage the JAAS module stacks, and must instead handle all authentication tasks directly.


            Is there a way to get a handle to a Security domain, by name, from within the JASPI layer, so I can then use JAAS modules normally?  The only alternative to this, if I want to use the standard LoginModules, would be to somehow manage my own JAAS context.

            • 3. Re: Multi-factor on the IDP
              Tim Kutz Newbie

              So, nobody knows any way to retrieve an existing security domain?


              I'm honestly rather shocked that there isn't support for handling any authentication tokens besides the Username and Password, or a client certificate.


              Also, it's pretty frustrating to see no response at all within a month.