5 Replies Latest reply on Apr 7, 2008 7:16 PM by gtomassoni

    Seam + NTLMSSP + user roles

    gtomassoni

      Dears,


      in a site I'm developing in Seam, I first attempted deploying the jcif's NTLMSSP authentication. Of course this works, because basically the NTLMSSP filter forwards to the servlet only requests from authenticated users.


      Then, I attempted implementing role-based authorizations. Roles are basically derived from the already-authenticated user names and are a almost direct mapping of the NT Domain groups to whose the users belong.


      This instead doesn't seem to work in seam: when I put an @Restrict annot the org.jboss.seam.security.NotLoggedInException gets fired.


      I of course developed my own authenticator.authenticate method and even attempted specifying every species of <web:authentication-filter> in components.xml I could imagine of.


      I also attempted fabricating my own version of the NTLMSSP filter, which fills the Identity instance with the authenticated data. Also attempted both instantiating this filter via web.xml and via @Filter.


      In summary, I guess I tried most of the possible ways. Not the right one, you say? Ok, tell me what it is, please: it seems to me seam reference docs are not that clear in this. They mostly speak about authorization, while authentication seems only possible through jaas, the seam login form, basic or digest.


      I would avoid to use jaas because this way I can't use the Seam's injection facility and it seems to me there is no way to specify a custom login mechanism in seam.


      Also, if the only feasible way is to implement a jaas LoginModule, how will this interact with Seam? Will it be possibile to use Component.get()? Do I need also to detect user roles in the LoginModule, or this is something that still need to be done in the #{authenticator.authenticate} method?


      Thank you,

        • 1. Re: Seam + NTLMSSP + user roles

          Just a filter is not enough as you need to make Seam 'think' that identity is logged in (and it's somewhat harder to do in 2.0.1 than in 2.0.0 without side effects).


          I've done some experimenting here:


          http://sdudzin.blogspot.com/2007/12/windows-sso-with-jboss-seam.html


          But official SSO support is still being developed (you can search in JIRA).

          • 2. Re: Seam + NTLMSSP + user roles
            gtomassoni

            Infact the problem I encountered was exactly that. Also, it seems my 2.0.1 wount use any jaas defined authentication, which would circumvent the problem I guess.


            Siarhei, thank you very much for your hint: I'm going to put it into my app.


            Just a question: is the following meant to circumvent a Seam redirection to the login form?


            <action execute=#{redirect.captureCurrentView}/>


            Thank you,

            • 3. Re: Seam + NTLMSSP + user roles

              Actually this looks more like an action that tries to remember the view you were trying to reach so that you continue to it after you logged in. I haven't actually looked at it in details.

              • 4. Re: Seam + NTLMSSP + user roles
                gtomassoni

                Ok, few updates and new troubles about this issue.


                I attempted using the hints from Siarhei ( http://sdudzin.blogspot.com/2007/12/windows-sso-with-jboss-seam.html ), but they seem not work with Seam 2.0.1.GA nor with 2.0.2.CR1.


                Then, I attempted developing a servlet filter miming the behaviour of org.jboss.seam.web.AuthenticationFilter.


                My filter is inserted into the Seam filter chain this way:


                
                @Name("jCifsAuthenticationFilter")
                
                @Scope(APPLICATION)
                
                @BypassInterceptors
                
                @Filter(within = "org.jboss.seam.web.exceptionFilter")
                
                @Startup
                
                public class JCifsAuthenticationFilter implements javax.servlet.Filter {
                
                ...
                
                }
                
                




                and of course it attempts authenticating the user. If it succeedes, it forwards the almost -plain- request it got to the downstreams chain through a:


                
                chain.doFilter(request, response);
                
                



                Before downstreaming the request, it of course obtains the session context associated to the request and sets the user Identity, but only if this has changed from the session known one (in order to avoid any useless credentialsUpdated event).


                
                Context ctx = new SessionContext(new ServletRequestSessionMap(req));
                
                Identity identity = (Identity)ctx.get(Identity.class);
                
                String userName = ntlm.getUsername();
                
                if(!userName.equals(identity.getUsername())) {
                
                    identity.setUsername(userName);
                
                    identity.setPassword("No, non è la BBC");
                
                }
                
                



                Also, an external authenticator.authenticate method is responsible for detecting user roles and for a further authentication step (in my app, users are allowed only if they belong to at least one role).


                So I have this in components.xml:


                
                <security:identity authenticate-method="#{authenticator.authenticate}" />
                
                




                Then, I of course used some @Restrict() to, well, restrict the availability of some app methods to the allowed users.


                Also, in pages.xml I defined some <exception ...> entry in order to detect NotLoggedInException (i.e.: people authenticated by the domain but not allowed to use the app) and AuthorizationException, and redirect to /unauthenticated.xhtml in case they get fired. The unauthenticated.xhtml view is simply a page saying something like sorry, this function is not allowed to you, please blah blah blah...


                Things seem to work fine at first, since the correct user is detected and NotLoggedInException and AuthorizationException exceptions are fired when expected. Also, app buttons get rendered and/or disabled according to the user roles, too.


                The problems are:


                1) When NotLoggedInException and AuthorizationException are fired, no redirection takes place at all. I even attempted with <http-error> instead of <redirect>, yielding no difference;


                2) no command actions are fired!!! I have some <commandButton action="#{pojo.method}"> which worked fine before I started using any authentication. Now they don't get invoked anymore.


                What's up? I'm downstreaming the exact request object I receive, apart some tweaking in the request's session in order to handle the two-phases NTLM authentication. However, during my tests POSTs request where already authenticated and nor request's session, nor the Identity object was even touched.

                • 5. Re: Seam + NTLMSSP + user roles
                  gtomassoni

                  Well, some updates.


                  I was totally wrong about 2): actions do get fired (a problem in the NTLM handshaking on POSTs).


                  But 1) still holds. I also attempted instantiating the JCIFS filter this way:


                  @Name("jCifsAuthenticationFilter")
                  
                  @Scope(APPLICATION)
                  
                  @BypassInterceptors
                  
                  @Filter(around = { "org.jboss.seam.web.redirectFilter", "org.jboss.seam.web.exceptionFilter" })
                  
                  @Startup
                  
                  



                  See? @Filter around both redirectFilter and exceptionFilter, which by the way allows the jCifs filter to be invoked before any other filter in the list. No relief.


                  Any idea?