3 Replies Latest reply on Aug 31, 2005 12:16 PM by evrim ulu

    jboss authentication service

    evrim ulu Newbie

      hi,

      i was facing most of the problems people have faced here. Although i've searched most of the literature, i didn't like most of the solutions. So, i decided to rephrase them and let people here direct me to the most appropriate solution.

      1) direct logging without accessing the secured content

      This problem occurs when one might want to put a login form to any page on his web site.

      Soln proposals:
      i) j_security_check filter: This solution is not portable so its crap
      ii) Simple hack: Posting to a secure region from user login form so that login form appers and redirects to j_security_check. This is what i've implemented and saw afterwards that it's also known by others:

      http://java.sys-con.com/read/37660.htm?CFID=116564&CFTOKEN=B88EB520-5ACB-B25F-325ACAF142017665

      I really didn't like hacks in my code, they'r always problems for future. Unfortunately, unless servlet spec changes, this will stay as is.

      2) Last Login List or Who are online now?

      We've faced this problem yesterday. We'r using container managed security and realized that we do not have any kind of control over the modules.

      Soln Proposals:
      i) j_security_check filter: crap go on,
      ii) tomcat valve : It's not a standart, it's tomcat based, poor performance solution, crap, go on.
      iii) CustomLoginModule: Yeah i've been thinking around this but i realized that i really don't need to write a new custom login module by extending some kind of JbossSpecificLogin module. Why? Simply because we need simple post_login() and pre_logout() hooks. Also, to pass any kind of data collected in the login module, i need to put them into db and grab them back with ejb from web. This results a poor,compilcated,unmaintainable solution. Also, since i only want to collect information about authentication, if i subclass some XLoginModule i'll never have a change to switch to other login modules and modularity of authentication sublimes. (IoC may solve the problem but i'm not sure for now) This is not what i want of course.

      Btw, can we access ejb's from loginmodule? I've seen an unanswered question about this.

      iv) AOP, this may be great if i can hook to login() of any module and get what i want. I couldn't find information about this but keep looking.

      Any ideas are welcome.

      Evrim.

        • 1. Re: jboss authentication service
          Scott Stark Master

          EJBs in the same domain as the login module cannot be accessed. Other domains should be fine.

          • 2. Re: jboss authentication service
            evrim ulu Newbie

            ok, let me phrase my solution. i'll try to cascase login modules.

            First, i'll flag jboss login modules as requisite afterwards add new custom login module (flagged as optional) so that i can record "user logged in" via slsb in the other security domain as you've said.

            This is good for me so that i can develop the security module in a seperate manner and don't waste built-in jboss modules.

            My question is how to developer custom login module. Answer is obvious but the problem is i don't want to put login module inside jboss classpath. Jboss must read it from my ejb project. So, i've searched and found ProxyLoginModule. Are there any documents about this ? How to extend, how to place custom module so that jboss is happy about it?

            • 3. Re: jboss authentication service
              evrim ulu Newbie

              let me propose my classpath solution. I've seen that ProxyLoginModule loads the module parameter class to use login module, this is not what i want.

              What about extending proxyLoginModule to JNDILoginModule? Which means i'll lookup login module from jndi and use it. By this way, i don't need to put my login module somewhere inside jboss but simply register it to jndi as a slsb which implements AbstractLoginModule.

              Any ideas welcome.

              evrim.