9 Replies Latest reply on May 28, 2003 5:38 AM by juhalindfors

    JBOSS JAAS implementation is broken

    hezekiel

      I'm posting this to save precious time from other.

      Yes, it is true that you can implement a custom login module in jboss. You can authenticate against the name and the password. But that's it. Forget about the various Callback implementations in javax.security.auth.callback (only the callbacks marked by * are supported)

      - ChoiceCallback
      - ConfirmationCallback
      - LanguageCallback
      - NameCallback *
      - PasswordCallback *
      - TextInputCallback
      - TextOutputCallback

      1st. reason is JBOSS's SecurityAssociationHandler.

      The handle method of SecurityAssociationHandler throws UnrecognizedCallbackException for all other callbacks in previous list. It handles only Name and Password callbacks plus some JBOSS internal callbacks.

      2.nd reason is that there's no separate login process in jboss.
      The invocation object, which is associated with each (remote)invocation contains the principal (name) and credential (password) info.

      When the invocation 'reaches' the SecurityInterceptor the principal is compared against the cache and if not found, authenticated against the configured JAAS login modules *using the principal and credential info* acquired from the Invocation.

      NameCallback and PasswordCallback get their data (indirectly) from the Invocation object.

      TextInputCallback (although implemented for some reason?! in JBOSS) cannot be used since no extra information is asked from client during the login process.

      I think that SUN put those other implementations there for a reason. Blatantly igoring them in JBOSS means that JBOSS cannot be J2EE certified.

      For comparison:
      If you write custom login modules for weblogic you can use all the callbacks mentioned earlier.

        • 1. Re: JBOSS JAAS implementation is broken
          hezekiel

          boost

          • 2. Re: JBOSS JAAS implementation is broken

            > I think that SUN put those other implementations
            > there for a reason. Blatantly igoring them in JBOSS
            > means that JBOSS cannot be J2EE certified.

            No, the EJB specification in no way, shape or form defines how the security context should be passed between the client and the server, or whether any type of callbacks should be propagated back to the client, or even if JAAS should be used in the first place to perform client authentication.

            If you need support for additional JAAS callbacks, submit a patch.

            • 3. Re: JBOSS JAAS implementation is broken
              hezekiel

              > No, the EJB specification in no way, shape or form
              > defines how the security context should be passed
              > between the client and the server, or whether any
              > type of callbacks should be propagated back to the
              > client, or even if JAAS should be used in the first
              > place to perform client authentication.

              Ok. But I still think that the login process should be a separate 'first class citizen' operation and not just something you do when you notice a new principal in security interceptor.

              > If you need support for additional JAAS callbacks,
              > submit a patch.

              Isn't that something Scott should do? ;-) I'm just too busy coding the app itself - there's definately no time for doing the 'server' too.

              Besides this isn't as trivial as it seems. Putting all this extra info in invocation object (the easy solution) is not reasonable. You definately don't want to send it _every_ time you make a remote call.

              The other option - separate login process requires changes at least in:

              - security interceptor:
              detect a login method invocation and extract the extra info from payload. (Placed there by the also modified ClientLoginModule)

              - SimplePrincipal needs to be modified or extended by a new one which supports these extra fields that different login modules require.

              - SecurityAssociationHandler (The principal and callback stuff)

              - probably much more changes - the SimplePrincipal is all over the place and changing/extending it might have a substantial effect...

              • 4. Re: JBOSS JAAS implementation is broken
                mnachev

                It seems that there is no reason to base strong projects using JBoss because the Security and JAAS possibilities are very important. For example we would like to do the following which is possible for WebLogic and other professional Application Servers, but for JBoss it is not true:

                1. Two steps Authorization using 1st page for Username and Password, and 2nd page for additional clarifications depends of the concrete user. Just after the 2nd page you can to determine the rights (roles).

                2. Hierarchy based security model which dynamicaly determine the user roles depending of some codnistions and/or hierarchy folder tree.

                • 5. Re: JBOSS JAAS implementation is broken
                  hezekiel

                  Scott? Are u listening? Are any of these features scheduled for Jboss 4?

                  • 6. Re: JBOSS JAAS implementation is broken

                    > Isn't that something Scott should do? ;-)

                    I'm sure he will once he has received your development support check. Or if you plead to him *nicely*.

                    > I'm just too busy coding the app itself - there's definately
                    > no time for doing the 'server' too.

                    Uh huh. Aren't we all?

                    In the mean time you can have a look at the SRP login module to maybe gain some ideas how to build exchange protocols between the client and the server.

                    • 7. Re: JBOSS JAAS implementation is broken
                      hezekiel

                      Juha, in no way I didn't mean to sound mean ;-). Ok I admit that I was a bit surprised by the way JAAS was implemented in JBoss - quite clean and effective but on the downside, almost impossible to extend. Thx for the SRP suggestion, maybe I'll take a look about that.

                      Right now the problem is solved by clients sending 'heartbeats' to server (at two minute intervals) which contain the local ip address + other stuff needed to distinguish different clients from each other. That way I also have the added benefit of being able to 'unregister' 'dead' clients fairly quickly from my own 'user management scheme'

                      Plus it's totally app server independent.

                      P.S.
                      Since you are trying to make money with JBoss why not make more of it by adding new features that attract new customers?

                      • 8. Re: JBOSS JAAS implementation is broken

                        > It seems that there is no reason to base strong
                        > projects using JBoss

                        Look it's fairly simple, really. If you still don't understand how the game works let me help you by listing your options:

                        1) sit and whine and get nothing done
                        2) start coding
                        3) beg someone to code it for you
                        4) pay someone to code it for you
                        5) buy weblogic

                        Is that clear? HTH

                        • 9. Re: JBOSS JAAS implementation is broken

                          > P.S.
                          > Since you are trying to make money with JBoss why not
                          > make more of it by adding new features that attract
                          > new customers?

                          Maybe that business model would work, maybe not.

                          I'm thinking like this: you want a feature that falls outside the J2EE spec, you pay me to code it, I make money. ;-)

                          Cheers,

                          -- Juha