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?


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.


Make sure the user which is running the tomcat has access to the folder where FreeShim is located.

sudo chmod -R a+rwx < dir of FreeShim >

This worked for me.