10 Replies Latest reply on Aug 18, 2004 9:36 PM by Neil Crow

    JBoss JAAS x Tomcat's

    Leandro Terra Melo Newbie

      I heard that JBoss' JAAS is not propagated to Tomcat (and vice-versa), is that true?

      If yes, does it mean that if authenticate using JBoss DatabaseServlerLogin for example, i won't be able to use methods such request.isUserInRole() in any servlets??

        • 1. Running Jboss examples on Windows
          Neil Crow Newbie

          Hope some one can help me on this.
          This is my configuration :
          I am using Windows XP (Prof Ed) JBoss 2.4.4, ant 1.4. J2SDK1.4
          I have tested the "try ant" example in the doc and it works. But when I try to build the Interest EJB example from my build directory, I mean from examples/build direcotry as

          ant ant intro-interest-jar

          I get this error
          Error while setting up environment for the application. Choose 'close' to terminate the application

          The message comes on Windows Popup and in the dos prompt I get :

          D:\J2EE\EJB\examples\build>ant intro-interest-jar
          Buildfile: build.xml

          BUILD FAILED

          D:\J2EE\EJB\examples\build\build.xml:16: java.lang.NullPointerException
          Any poniters to solve this problem will be appreciated.


          • 2. Re: jeeez I've understood PN model security !
            Neil Crow Newbie

            > Hey cooper can you explain how is this done on a
            > simple example, from core module's permissions. Let's
            > say:
            > 2:200:block:menu:published:youraccount:main:.*
            > or
            > 2:200:module:youraccount:published:user:(edithome|edit
            > ser|chgtheme|logout):.*

            let's explain the second rule.

            okay, if you look at module youraccount you will see the code :

            if (api.secAuthAction(
            moduleMetaData.getName() + ":" + operationMetaData.getName() + ":",
            // then display an icon + a link

            the rule :


            you have to split it :

            2 : group ID
            200 : acces read
            module:youraccount:published : component instance
            user:(edithome|edituser|chgtheme|logout):.* : test instance

            that means that plain users will be able to display
            link in youraccount module to the module operation :

            user : edithome
            user : editusr
            user : chgtheme
            user : logout

            when api.secAuthAction is called
            it will say yes for module meta data
            user and operation metadata edithome, editusr, chgtheme, logout.

            basically the rule

            "module:youraccount:published" will match the componentinstance : "module:youraccount:published"

            because string are same (but first must be thought as a regular expression)

            "user:(edithome|edituser|chgtheme|logout):.*" will match all constructed string such as
            "user:edithome:" for instance.

            I hope it's clear enough.

            The best is to check CoreModule security and the class SecurityRule.

            Nukes security is quite hard to figure out but once you've understood it's clear. But it's not easy to explain it.

            Remember : security rules are stupid regular expression, a-la-unix.


            > This is confusing ...
            > Thanks,
            > Alex.

            • 3. Re: JBoss JAAS x Tomcat's
              dev2gosoft Newbie

              Security context is propagated in JBoss-Tomcat. I use the databaseserverloginmodule to authenticate and i can use methods like reqest.isUserInRole etc.

              • 4. Re: JBoss JAAS x Tomcat's
                Leandro Terra Melo Newbie

                Not really!

                dev2gosoft, if you use DatabaseServerLoginModule, i guess somewhere in your application the user needs to log in, am i correct.

                I also have strong feeling that in your login page you use an action="j_security_check". Allright, if so, that's why the propagation of JBoss/Tomcat works.

                However, there are situation that we want to point our login page to another specific action, for instante, a action="MyLogonAction".This is very common if you're working with Struts (your action could be something like action="/MyLogonAction.do").
                Inside this MyLogonAction class, wich is basically an ordinary servlet you would create your LoginContext and log the user in.
                That's right there where the problem begins. If you log from inside this Servlet, you're logged allright in JBoss, but Tomcat doesn't know anything about that.

                Get more information right here.

                • 5. Re: JBoss JAAS x Tomcat's
                  stueccles Newbie

                  Its pretty simple.

                  If you do not use the Tomcat Authenticators (BASIC,DIGEST,FORM,CERT) your principal and roles will not be know in request.getPrincipal() and isUserInRole() and security-constraints in web.xml will not work.

                  If you use Jaas from a Login Context without using the JBoss security manager neither Tomcat nor JBoss will know about your authentication, user principal or role.

                  This is because Tomcat Authenticator doesnt use Jaas (never has) it delegates to a Realm (in this case JBossSecurityMgrRealm) which delegates to JBossSecurityManager which then uses Jaas. only by this process (or by replicating it) is the principal/roles known to Tomcat and JBoss.

                  This is NOT solved in JBoss4 as it is not a bug, it is just the way J2EE security works.

                  You have choices:
                  * Roll your own security system using an object in the session and filters.
                  * Write a custom tomcat authenticator.

                  I think its very well explained in the struts mailing list post you mention

                  • 6. Re: JBoss JAAS x Tomcat's
                    Leandro Terra Melo Newbie

                    I have strong feellings that you just didn't read the article i sent.

                    I'm using a FORM based authentication.

                    If you take a look at the discussion i sent (just click on that link and you'll see) you'll understand what i'm taliking about.

                    And this is a JBoss/Tomcat problem. Just try what i said (or what the discussion says) in any other server and you'll see it works.

                    • 7. Re: JBoss JAAS x Tomcat's
                      Leandro Terra Melo Newbie

                      I just would like to fix a little bit of my last post.

                      Actually, i (myself) have never tried to do that in other j2ee servers, but this information came to me as the same way as the one of the jboss/tomcat problem. In other words, i trust the people who gave me this information.

                      But anyway, as i didn't test it myself, i recognize that i couldn't post it with the confidence that i did.

                      • 8. Re: JBoss JAAS x Tomcat's
                        Scott Stark Master

                        Doing a JAAS login is independent of the FORM auth used to access secured web content. You cannot do a JAAS login from within a servlet and affect the secured identity tomcat sees at the web container level unless you create a custom FormAuthenticator or tomcat valve which interacts with the JAAS layer. This is outside of the scope of the j2ee security model and not supported expect by low level application server specific mechanisms.

                        • 9. Re: JBoss JAAS x Tomcat's
                          Jian Suo Newbie

                          everyone always talks about mechanisms,but the problem is still there,the best way is give me a sample,who can give me a sample?

                          • 10. Re: JBoss JAAS x Tomcat's
                            Scott Stark Master

                            There is no coupling between a session and the security domain cache. If you want that behavior its a simple matter of adding a session listener that invalidates the cache through jmx. I'll add a session listener that does this to the dist for 3.2.6RC2/4.0.0