Authorization with Resin

Overview
Installation
Configuration
Quercus
SOA/IoC
JSP
Servlets and Filters
Admin (JMX)
EJB
Amber
Security
Performance
Hessian
XML and XSLT
Third-party
Troubleshooting/FAQ

Authentication
Digest Passwords
Authorization
SSL
Security Manager
Malicious Attacks
FAQ
Scrapbook

Digest Passwords

Security

SSL

Authorization is used to mark sections and resources of a web site that have limited access. Constraints are used to indicate the criteria for access, typically the constraint is based on a user login, but it can also include such things as limiting access to clients from a certain ip address and requiring that a secure transport such as SSL is in use.

Security Constraints

security-constraint

child of web-app

Selects protected areas of the web site. Sites using authentication as an optional personalization feature will typically not use any security constraints. Sites using authentication to limit access to certain sections of the website to certain users will use security constraints.

Security constraints can also be custom classes.

Protecting all pages for logged-in users

<web-app>
  ...
<security-constraint>
  <web-resource-collection>
    <url-pattern>/*</url-pattern>
  </web-resource-collection>
  <auth-constraint role-name='user'/>
</security-constraint>
  ...
</web-app>

web-resource-collection

child of security-constraint

Specifies a collection of areas of the web site.

url-pattern	url patterns describing the resource
http-method	HTTP methods to be restricted.

auth-constraint

child of security-constraint

Requires that authenticated users fill the specified role. In Resin's JdbcAuthenticator, normal users are in the "user" role. Think of a role as a group of users.

role-name

Roles which are allowed to access the resource.

Protecting webdav for webdav users

<security-constraint>
  <auth-constraint role-name='webdav'/>

  <web-resource-collection>
    <url-pattern>/webdav/*</url-pattern>
  </web-resource-collection>
</security-constraint>

ip-constraint

child of security-constraint

Allow or deny requests based on the ip address of the client. ip-constraint is very useful for protecting administration resources to an internal network. It can also be useful for denying service to known problem ip's.

Admin pages allowed from 192.168.17.0/24

<security-constraint>
  <web-resource-collection>
    <url-pattern>/admin/*</url-pattern>
  </web-resource-collection>

  <ip-constraint>
    <allow>192.168.17.0/24</allow>
  </ip-constraint>
</security-constraint>

The /24 in the ip 192.168.17.0/24 means that the first 24 bits of the ip are matched - any ip address that begins with 192.168.17. will match. The usage of /bits is optional.

Block out known trouble makers

<security-constraint>
  <ip-constraint>
    <deny>205.11.12.3</deny>
    <deny>213.43.62.45</deny>
    <deny>123.4.45.6</deny>
    <deny>233.15.25.35</deny>
    <deny>233.14.87.12</deny>
  </ip-constraint>

  <web-resource-collection>
    <url-pattern>/*</url-pattern>
  </web-resource-collection>
</security-constraint>

Be careful with deny - some ISP's (like AOL) use proxies and the ip of many different users may appear to be the same ip to your server.

allow	add an ip address to allow	default is to allow all ip addresses
deny	add an ip address to deny	default is to deny no ip addresses
error-code	error code to send if request is denied	403
error-message	error message to send if request is denied	Forbidden IP Address
cache-size	cache size, the result of applying rules for an ip is cached for subsequent requests	256

If only deny is used, then all ip's are allowed if they do not match a deny. If only allow is used, then an ip is denied unless it matches an allow. If both are used, then the ip must match both an allow and a deny

user-data-constraint

child of security-constraint

Restricts access to secure transports, i.e. SSL.

transport-guarantee

Required transport properties. NONE, INTEGRAL, and CONFIDENTIAL are allowed values.

<security-constraint>
  <user-data-constraint>
    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
  </user-data-constraint>

  <web-resource-collection>
    <url-pattern>/*</url-pattern>
  </web-resource-collection>
</security-constraint>

The default behaviour is for Resin to rewrite any url that starts with "http:" by replacing the "http:" part with "https:", and then send redirect to the browser.

If the default rewriting of the host is not appropriate, you can set the secure-host-name for the host:

  <host id='...'>
    <secure-host-name>https://hogwarts.com</secure-host-name>

 ...

  <host id='...'>
    <secure-host-name>https://hogwarts.com:8443</secure-host-name>

  ...

transport-guarantee

Restricts access to secure transports, i.e. SSL.

constraint

child of security-constraint

Defines a custom constraint. The custom constraint specifies a resin:type which extends com.caucho.server.security.AbstractConstraint. Bean-style initialization is used to initialize the constraint.

...
<security-constraint>
  <constraint resin:type="example.CustomConstraint>
    <init>
      <policy>strict</policy>
    </init>
  </constraint>
  <web-resource-collection url-pattern='/*'/>
</security-constraint>
...

Custom Security Constraints

Any custom security constraint is checked after any authentication (login) but before any filters or servlets are applied. The security constraint will return true if the request is allowed and false if it's forbidden. If the request is forbidden, it's the constraint's responsibility to use response.sendError() or to return an error page.

package example;

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import com.caucho.server.security.*;

public class CustomSecurity extends AbstractConstraint {
  private String foo = "false";

  public void setFoo(String foo)
  {
    this.foo = foo;
  }

  public boolean needsAuthentication()
    return false;
  }

  public boolean isAuthorized(HttpServletRequest request,
                              HttpServletResponse response,
                              ServletContext application)
    throws ServletException, IOException
  {
    if (foo.equals(request.getParameter("test")))
      return true;

    response.sendError(response.SC_FORBIDDEN);

    return false;
  }
}

The needsAuthentication method tells Resin that it needs to log in the user before checking the authorization. This would allow the custom authorizer to check user roles or the user principle for the proper permissions.

<constraint resin:type="example.CustomSecurity">
  <foo>test-value</foo>
</constraint>

Protecting static files from viewing by anyone

Sometimes it is necessary to protect files from being viewed by anyone, such as configuration files used in your code but not meant to be served to a browser.

Place files in WEB-INF

Place files in WEB-INF or a subdirectory of WEB-INF. Any files in WEB-INF or it's subdirectories will automatically be protected from viewing.

Security constraint requiring role nobody

Use a security constraint that requires a role that nobody will ever have.

security-constraint to protect static files

<web-app>
  ...
  <!-- protect all .properties files -->
  <security-constraint>
    <web-resource-collection>
      <url-pattern>*.properties</url-pattern>
    </web-resource-collection>
    <auth-constraint role-name='nobody'/>
  </security-constraint>

  <!-- protect the config/ subdirectory -->
  <security-constraint>
    <web-resource-collection>
      <url-pattern>/config/*</url-pattern>
    </web-resource-collection>
    <auth-constraint role-name='nobody'/>
  </security-constraint>
  ...
</web-app>

A servlet that returns a 403 error

Use a simple servlet that returns a 403 error, which means "Forbidden". Resin provides the servlet com.caucho.servlets.ErrorStatusServlet which is useful for this:

Using ErrorStatusServlet to protect static files

<web-app>
  ...
  <servlet>
    <servlet-name>forbidden</servlet-name>
    <servlet-class>com.caucho.servlets.ErrorStatusServlet</servlet-class>
    <init>
      <status-code>403</status-code>
    </init>
  </servlet>

  <servlet-mapping url-pattern="*.properties" servlet-name="forbidden"/>
  <servlet-mapping url-pattern="/config/*" servlet-name="forbidden"/>
  ...
</web-app>

Or you could implement your own servlet:

servlet to protect static files - WEB-INF/classes/example/servlets/Forbidden.java

package example.servlets;

import javax.servlet.*;
import javax.servlet.http.*;

import java.io.IOException;

/**
 * Respond with a 403 error
 */
public class Forbidden extends GenericServlet {
  public void service(ServletRequest request, ServletResponse response)
    throws ServletException, IOException
  {
    HttpServletResponse res = (HttpServletResponse) response;
    res.sendError(403);
  }
}

Digest Passwords

Security

SSL