To "protect" a Tomcat Application or other J2EE Protected Resource, then you will need to modify the web.xml or context.xml file for the application.
Typically, for Tomcat it is found $CATALINA_HOME/webapps/DirectoryWiki/WEB-INF

As shown in the preceding example, the <web-app> element is the root element for web applications. The <web-app> element contains the following elements that are used for specifying security for a web application:

The security role reference element contains the declaration of a security role reference in the web application’s code.

<declaration> - an optional description of the role

<role-name> - the security role name used in the code

<role-link> - optional element used to link a security role reference to a defined <role-name>.

The security <role-name> specified here is the security role name used in the code. The value of the <role-name> element must be the String used as the parameter to the HttpServletRequest.isUserInRole(String role) method. The container uses the mapping of security-role-ref to security-role when determining the return value of the call.

The security <role-link> specified here contains the value of the name of the security role that the user may be mapped into. The role-link element is used to link a security role reference to a defined security role. The role-link element must contain the <role-name> of one of the security roles defined in the security-role elements.

A security role is an abstract name for the permission to access a particular set of resources in an application. A security role can be compared to a key that can open a lock. Many people might have a copy of the key. The lock doesn’t care who you are, only that you have the right key.

The security-role element is used with the security-role-ref element to map roles defined in code to roles defined for the web application. For more information about security roles, read Working with Security Roles.

A little more explanation for the <url-pattern> element is required. The request URI is the part of a URL after the hostname and port. For example, let’s say that you have an ecommerce site with a catalog that you would want anyone to be able to access and browse, and a shopping cart area for customers only. You could set up the paths for your web application so that the pattern /cart/* is protected but nothing else is protected. Assuming that the application is installed at context path /myapp, the following are true:

http://localhost:8080/myapp/index.xhtml is not protected.

http://localhost:8080/myapp/cart/index.xhtml is protected.

A user will be prompted to log in the first time he or she accesses a resource in the cart/ subdirectory.

An HTTP method is protected by a <web-resource-collection> under any of the following circumstances:

If the HTTP method is not named in either <http-method> or <http-method-omission> of the <web-resource-collection> (which implies that all are protected)

If the collection specifically names the HTTP method in an <http-method> subelement

If the collection contains one or more <http-method-omission> elements, none of which names the HTTP method

Authorization constraints indicate which users in specified roles which are Authorized to access to the <web-resource-collection>. The <role-name> specified here must either correspond to the <role-name> of one of the <security-role> elements defined for this web application, or be the specially reserved role name *, which is a compact syntax for indicating all roles in the web application.

User data constraints specify network security requirements, in particular, this constraint specifies how data communicated between the client and the container should be protected. If a user transport guarantee of INTEGRAL or CONFIDENTIAL is declared, all username and password information will be sent over a secure connection using HTTP over SSL (HTTPS).

The login configuration element is used to specify the user authentication Method to be used for access to web content, the realm in which the user will be authenticated, and, in the case of form-based login, additional attributes. When specified, the user must Authenticate before access to any resource that is constrained by a security constraint will be granted.

When a user attempts to access a web resource that is constrained by a <security-constraint> element, the web container activates the authentication mechanism that has been configured for that resource. The authentication mechanism specifies how the user will be prompted to log in. If the <login-config> element is present and the <auth-method> element contains a value other than NONE, the user must be authenticated to access the resource. If you do NOT specify an authentication mechanism, authentication of the user is not required.

The types of user authentication methods are defined in the <auth-method> element and the values supported include: