Q:

How to fix access to the requested resource which has been denied for Tomcat webapp?

I have installed Tomcat in my machine and it is running fine. I am able to login to the administration manager. I have deployed a .war file which can be viewed on the Tomcat manager. The name of the file is shim (actually I am installing freeshim).
When I try to access shim on the browser using 192.168.1.65:8080/shim I get a web administration interface of the shim. This is the message I get:

This is the web administration interface for FreeSHIM. Web services are located "here".

When I click "here" in order for me to configure the Freeshim I get an error:

HTTP Status 403 - Access to the requested resource has been denied.

Where am I going wrong? How can I change this permission?

A:

HTTP Status 403 (Access to the requested resource has been denied) can indicate that either you typed 3+ incorrect credentials (try another web-browser) or you've some problem with configuration.
If you have not changed any configuration files, please examine the file conf/tomcat-users.xml in your installation (locate tomcat-users.xml). That file must contain the credentials to let you use Tomcat webapp.
For example, to add the manager-gui role to a user named tomcat with a password of s3cret, add the following to the config file listed above:
<role rolename="manager-gui"/>
<user username="tomcat" password="s3cret" roles="manager-gui"/>

Then you can access your webapps manager from /manager/html (e.g. reloading after config changes).
Read more: Manager App HOW-TO
If you're trying to implement your own security constraint (in web.xml), try the following example (before </web-app> ending):
<!-- This security constraint protects your webapp interface. -->
<login-config>
  <!-- Define the Login Configuration -->
  <auth-method>BASIC</auth-method>
  <realm-name>Webapp</realm-name>
</login-config>
<security-constraint>
  <web-resource-collection>
    <web-resource-name>Admin</web-resource-name>
    <url-pattern>/*</url-pattern>
    <http-method>GET</http-method>
    <http-method>POST</http-method>
  </web-resource-collection>
  <auth-constraint>
    <role-name>*</role-name>
  </auth-constraint>
  <!-- Specifying a Secure Connection -->
  <user-data-constraint>
    <!-- transport-guarantee can be CONFIDENTIAL (forced SSL), INTEGRAL, or NONE -->
    <transport-guarantee>NONE</transport-guarantee>
  </user-data-constraint>
</security-constraint>
<!-- Authorization, see: tomcat-users.xml --> 
<security-role>
  <role-name>*</role-name>
</security-role>

If you still having the problem, try:

check if you're editing the right XML file,
validate your XML files, e.g. catalina.sh configtest or xmlstarlet val /etc/tomcat?/*.xml /var/lib/tomcat7/webapps/*/WEB-INF/*.xml,
your <url-pattern> matches in your <security-constraint> or set to /*,
check your Tomcat logs (e.g. /var/log/tomcat7),
increase logging level (INFO -> FINE/FINEST) in logging.properties or log4j.properties (INFO, SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST or ALL), restart Tomat and check the logs,
if nothing in logs, check if you're checking the right logs (sudo lsof | grep -E "java.*(out|txt|log)$", tail -f /var/log/tomcat7/*.log /var/log/tomcat7/*.txt /var/log/tomcat7/*.out),
when using log4j logging system, make sure you initialized it properly by placing libs and log4j.properties into the right folder and configuring it,
test BASIC authentication with cURL:

without credentials:
$ curl -vv http://example.com:8983/solr/

Normally request should return HTTP/1.1 401 Unauthorized and the "WWW-Authenticate" header should indicate Basic authentication is required.
with credentials:
$ curl -vv -u tomcat:tomcat http://example.com:8983/solr/

The request should be sent with an "Authorization" header and it should authenticate.  If your credentials are invalid, you should get: HTTP/1.1 401 Unauthorized. If the user is authenticated, but does not have access to view the resource you should get: HTTP/1.1 403 Forbidden.

maybe a user lock out mechanism has been activated for too many failed authentication attempts (LockOutRealm),
stop and run Tomcat manually (in the same way as in: ps wuax | grep ^tomcat), e.g.:
# ps wuax | grep ^tomcat
tomcat7    884  /usr/lib/jvm/java-7-openjdk-amd64/bin/java -Djava.util.logging.config.file=/var/lib/tomcat7/conf/logging.properties ... org.apache.catalina.startup.Bootstrap start
$ /etc/init.d/tomcat7 stop
$ sudo sudo -u tomcat7 /usr/lib/jvm/java-7-openjdk-amd64/bin/java ...  -Dorg.apache.catalina.level=FINEST org.apache.catalina.startup.Bootstrap start

Alternatively start using catalina.sh script like:
$ . /etc/default/tomcat7
$ export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64 CATALINA_HOME=/usr/share/tomcat7 CATALINA_BASE=/var/lib/tomcat7 CATALINA_PID=/var/run/tomcat7.pid CATALINA_TMPDIR=/tmp LOGGING_CONFIG="-Dorg.apache.catalina.level=FINEST"
$ /usr/share/tomcat7/bin/catalina.sh run

Or in debug mode:
$ JPDA_SUSPEND=y catalina.sh jpda start

and check your catalina.out log.
last resort is to debug process by: sudo strace -fp PID.

