Thanks, this pointed me in the wrong direction. I then ended up calling this
from within the onBeforeRender method to get it to handle the redirect
correctly on login. Another issue was that I was calling another part of the
code and should have been calling AuthenticatedWebSession.get().signIn

So, what I was now trying is to have the login process handle the situation
when a windows / ntlm userid is not found and fall back to the 'legacy' form
based log in.

I am able to display the form, however, the form post never seems to work.
Checking the source code of the html sent to the browser, the form is
defined there, and if I construct a url with the form fields  it works, and
the fields are available inside the wicket code. But they're not there when
I post the form.

If I set a property to ignore the ntlm process and start with a new browser,
the login form works fine.

Any thoughts? I guess I'll try and compare the html generated to see if
there is any difference. I'll also double check the program flow if the ntlm
is called but the authentication fails.

Thanks - Bryan.

On Sun, Mar 21, 2010 at 9:17 PM, Josh Chappelle <jchappe...@4redi.com>wrote:

> Bryan,
>
> We have an NTLMPage that we redirect the browser to. If there is no
> authorization header this is what we do.
>
> String auth = request.getHeader("Authorization");
>                if (auth == null)
>                {
>                        setRedirect(false);
>                response.setHeader("WWW-Authenticate", "NTLM");
>                throw new AbortWithHttpStatusException(401, false);
>
>                }
>
> I hope this helps.
>
> Thanks,
>
> Josh
>
> -----Original Message-----
> From: Bryan Montgomery [mailto:mo...@english.net]
> Sent: Friday, March 19, 2010 3:36 PM
> To: users@wicket.apache.org
> Subject: Help with integrating NTLM in wicket application
>
> Hello,
> I have two applications, one a stand alone web app and one wicket based.
> Currently they both use form authentication however I am trying to add NTLM
> authentication for SSO from our windows intranet.
>
> Leveraging jcifs, I've been able to do this pretty easily with the stand
> alone web app. However I've been struggling over the last couple of days
> with the wicket app.
>
> I'll preface this with the caveat that I have only done some very simple
> stuff with wicket to date.
>
> The flow is that the user makes a request and the program flow is
> redirected
> to LoginPage, and in turn to LoginPanel. In LoginPanel the first thing it
> does is check if there is an authentication header, if not which is the
> case, it sets the status to SC_UNAUTHORIZED and adds a header of
> "WWW-Authenticate: NTLM". I then started with flushing the response and not
> adding anything else.
>
> In theory this response should tell the browser to resubmit the same
> request
> with the authentication information. However, from our log files I can see
> that the request second time around only has the Login in the request
> cycle,
> compared to the startup page being in the request cycle initally.
>
> After looking on the web I've tried various combinations including trying
> continueToOriginalDestination in the onBeforeRender method.
>
> One thing I've noticed is that it seems that setting the status and header
> on the
> ((WebResponse)response).getHttpServletResponse() only takes effect when I
> do
> not call flushBuffer() on it. This subseqently throws an exception in the
> wicket processing because the response has already been closed.
>
> I feel that I am so close - but can't quite get it right!
>
> I was hoping to integrate this with minimal changes to the code but am
> thinking that maybe I should start from scratch? I've found a few posts
> online of similar situations but I haven't been able to put all the pieces
> together yet.
>
> Appreciate the help in getting this sorted out.
>
> Thanks,
> Bryan.
>
>
> http://markmail.org/message/cjy4o4ndtigius55#query:+page:1+mid:t3foamferfh2t
> wwj+state:results
>
> http://old.nabble.com/Wicket-NTLM-Single-sign-on-integration-Question-td1786
> 8669.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Reply via email to