-
1. Re: Seam + NTLMSSP + user roles
svadu Apr 4, 2008 9:35 PM (in response to gtomassoni)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 Apr 4, 2008 9:49 PM (in response to 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
svadu Apr 4, 2008 10:00 PM (in response to gtomassoni)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 Apr 7, 2008 4:14 PM (in response to 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 likesorry, 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 Apr 7, 2008 7:16 PM (in response to 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?