|
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.
<web-app>
...
<security-constraint>
<web-resource-collection>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint role-name='user'/>
</security-constraint>
...
</web-app>
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.
|
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.
|
<security-constraint>
<auth-constraint role-name='webdav'/>
<web-resource-collection>
<url-pattern>/webdav/*</url-pattern>
</web-resource-collection>
</security-constraint>
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.
<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.
<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
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>
Restricts access to secure transports, i.e. SSL.
security-constraint
Defines a custom constraint. The custom constraint specifies a resin:type which extends .
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>
...
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>
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 or a subdirectory of WEB-INF. Any files in
WEB-INF or it's subdirectories will automatically be protected
from viewing.
Use a security constraint that requires a role that nobody
will ever have.
<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>
Use a simple servlet that returns a 403 error, which means
"Forbidden". Resin provides the servlet which is useful for
this:
<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:
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);
}
}
Copyright (c) 1998-2009 Caucho Technology, Inc. All rights reserved. caucho® ,
resin® and
quercus®
are registered trademarks of Caucho Technology, Inc.
|