2 Replies Latest reply on Mar 13, 2013 6:48 PM by tomeicher

    propagate JAAS principal to web request / session

    tomeicher
    tomeicher Mar 1, 2013 6:30 PM

      Hello,

      I have a EAR=WAR+JAR application using Wicket6 running inside AS7.1

      I would like to make use of the AuthorizationInterceptor to secure my EJB methods.

      In my Wicket Login Page, I can now authenticate my Principal using a custom LoginModule, etc that works fine.

      But at the next page request, the JAAS context is gone, and the call is performed by "anonymous".

       

      Q1. If I had auth configuations in web.xml, jboss-web.xml etc (which I don't actually want that much ;-), would then the JBoss/Tomcat propagate the security context within the tomcat session ?

      Or are there filters or valves who would automatically do this for me ?

       

      Q2. If no, could I not just store the Principal instance from the first successfull JAAS login to my web session and restore it in my base page for every other request ? But I found no simple setPrincipal() call anywhere ;-)

      Any ideas how to tackle this ?

       

      I don't mind using Authentication, since I already have the working LoginModule now, but actually, I just want to do authorization, i.e. put a @RolesAllowed({"role", "another"}) on my EJB method and be sure that no Principal without a matching roles accesses the method...

       

      Any input appreciated :-)

      Thanks, Tom.

        • 1. Re: propagate JAAS principal to web request / session
          tomeicher
          tomeicher Mar 5, 2013 6:19 PM (in response to tomeicher)

          some stuff learned:

          • In my Wicket Base Page, I need to setup a Configuration that has my custom login module to setup stuff, roles, etc
          • plus the ClientLoginModule which will setup propagation to the EJB layer (only this one does it, according to docs in some places)
          • the LoginModule needs to setup the roles.
          • In order to do so, it needs an instance of my "User" class, to get the roles from the database. To get to those, I need to lookup an EJB since the LoginModule does not have access to PersistenceContext et all
          • and since I have a <s:security-domain> for <ejb-name>*</ejb-name> in my EJB layer, the one EJB that is used from the LoginModule must live in another place (WAR or different EAR) so it can be called to setup JAAS without an existing security-domain. (endless loop trying to setup security in order to setup security ... otherwise)

          Phew, that was some work.

          The only stupid thing I see now, is that JAAS is setup twice, once from WAR layer ("client") and once from EJB layer ("server"), if I saw that correctly.

          Any ideas, suggestions, comments, etc so far anyone ?

            • Actions
          • 2. Re: propagate JAAS principal to web request / session
            tomeicher
            tomeicher Mar 13, 2013 6:48 PM (in response to tomeicher)

            In case you are trying to do something similar silly: DONT !

            Save yourself 5 nights of frustating hacking, and just build your own @SessionScoped call context in the web layer, and check it with a standard default EJB interceptor at the ejb layer.

            no magic involved, works in one night, 4 nights off to the pub !

             

            Despite the ugly and silly LoginModule callback and JAAS Configuration coding (40+ lines to set a user and password you already have in two Strings), unless the WAR is not secured in itself, you will have to setup JAAS for every call, even AJAX etc, making it not easier with e.g. Wicket. And once you have that, you realize that JAAS/PicketBox will just "cache" the credentials on the server side for as long as it thinks is cool, allowing access to client you already have revoked access from. Code for clearing the JAAS cache found on the net would win some obfuscation contest, but will not work with a deployed (not configured in server) security-domain - only those defined in standalone.xml will be visible e.g. from CLI...

              • Actions