...
First of all the difference between authentication and authorization should be mentioned. It is that authentication determines who is currently using software and authorization determines if user has access to certain resource. In the case of integrating servlet container authentication with Wicket, servlet container will authenticate user and Wicket will authorize him.
There might be several ways to do it, but . I found the following way most convenient. The idea is to define security constraint for the login page only while using Wicket authorization to redirect user to that login page. So that when user goes to a page that requires authorization Wicket redirects user to the login page which activates servlet container authentication. User logges in. User name and user roles are available from HttpServletRequest and can be put in Wicket session to use them for Wicket authorization. To make it more concrete here is some code.
...
If you want to login before you go to any secured page (like login panel on every page), servlet container authentication can cause problems because a secure page must be accessed before user can authenticate. There's common workaround that I is used in the LoginPage class. If it's not your case LoginPage class can be empty and LoginPage.html can post directly to j_security_check.
...
And the main advice on this kind of integration is to avoid it if you can. Wicket authentication is much nicer ïŠ