resin-security.xtp

来自「RESIN 3.2 最新源码」· XTP 代码 · 共 1,899 行 · 第 1/5 页

<example title="Protecting all pages for logged-in users">
&lt;web-app&gt;
  ...
&lt;security-constraint&gt;
  &lt;web-resource-collection&gt;
    &lt;url-pattern&gt;/*&lt;/url-pattern&gt;
  &lt;/web-resource-collection&gt;
  &lt;auth-constraint role-name='user'/&gt;
&lt;/security-constraint&gt;
  ...
&lt;/web-app&gt;
</example>
</s2>

<s2 title="web-resource-collection" type="defun">
<parents>security-constraint</parents>

<p>Specifies a collection of areas of the web site.</p>

<deftable-childtags>
<tr><td>url-pattern</td><td>url patterns describing the resource
</td></tr><tr><td>http-method</td><td>HTTP methods to be restricted.
</td></tr></deftable-childtags>
</s2>

<s2 title="auth-constraint" type="defun">
<parents>security-constraint</parents>

<p>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.</p>

<deftable-childtags>
<tr><td>role-name</td><td>Roles which are allowed to access the resource.
</td></tr></deftable-childtags>

<example title="Protecting webdav for webdav users">
&lt;security-constraint&gt;
  &lt;auth-constraint role-name='webdav'/&gt;

  &lt;web-resource-collection&gt;
    &lt;url-pattern&gt;/webdav/*&lt;/url-pattern&gt;
  &lt;/web-resource-collection&gt;
&lt;/security-constraint&gt;
</example>

</s2>

<s2 title="ip-constraint" version="Resin 2.0.6" type="defun">
<parents>security-constraint</parents>

<p>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.</p>

<example title="Admin pages allowed from 192.168.17.0/24">
&lt;security-constraint&gt;
  &lt;web-resource-collection&gt;
    &lt;url-pattern&gt;/admin/*&lt;/url-pattern&gt;
  &lt;/web-resource-collection&gt;

  &lt;ip-constraint&gt;
    &lt;allow&gt;192.168.17.0/24&lt;/allow&gt;
  &lt;/ip-constraint&gt;
&lt;/security-constraint&gt;
</example>

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

<example title="Block out known trouble makers">
&lt;security-constraint&gt;
  &lt;ip-constraint&gt;
    &lt;deny&gt;205.11.12.3&lt;/deny&gt;
    &lt;deny&gt;213.43.62.45&lt;/deny&gt;
    &lt;deny&gt;123.4.45.6&lt;/deny&gt;
    &lt;deny&gt;233.15.25.35&lt;/deny&gt;
    &lt;deny&gt;233.14.87.12&lt;/deny&gt;
  &lt;/ip-constraint&gt;

  &lt;web-resource-collection&gt;
    &lt;url-pattern&gt;/*&lt;/url-pattern&gt;
  &lt;/web-resource-collection&gt;
&lt;/security-constraint&gt;
</example>

<p>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.</p>

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

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

</s2>

<s2 title="user-data-constraint" type="defun">
<parents>security-constraint</parents>

<p>Restricts access to secure transports, i.e. SSL.</p>

<deftable-childtags>
<tr><td>transport-guarantee</td><td>Required transport properties.  NONE,
INTEGRAL, and CONFIDENTIAL are allowed values.
</td></tr></deftable-childtags>

<example>
&lt;security-constraint&gt;
  &lt;user-data-constraint&gt;
    &lt;transport-guarantee&gt;CONFIDENTIAL&lt;/transport-guarantee&gt;
  &lt;/user-data-constraint&gt;

  &lt;web-resource-collection&gt;
    &lt;url-pattern&gt;/*&lt;/url-pattern&gt;
  &lt;/web-resource-collection&gt;
&lt;/security-constraint&gt;
</example>

<p>
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.
</p>

<p>
If the default rewriting of the host is not appropriate, you can set the
<a config-tag="secure-host-name"/> for the host:
</p>

<example>
  &lt;host id='...'&gt;
    &lt;secure-host-name&gt;https://hogwarts.com&lt;/secure-host-name&gt;

 ...
</example>

<example>
  &lt;host id='...'&gt;
    &lt;secure-host-name&gt;https://hogwarts.com:8443&lt;/secure-host-name&gt;

  ...
</example>

</s2>

<s2 title="transport-guarantee" type="defun">
<p>Restricts access to secure transports, i.e. SSL.</p>
</s2>

<s2 title="constraint" version="Resin 2.0.1" type="defun">
<parents>security-constraint</parents>

<p>Defines a custom constraint.  The custom constraint specifies a <var>resin:type</var> which extends <a href="javadoc|com.caucho.server.security.AbstractConstraint|"/>.  
<a href="ioc-bean.xtp">Bean-style initialization</a> is used to
initialize the constraint.</p>

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

</s2>

</s1> <!-- Security-Constraints -->


<s1 title="Custom Security Constraints">

<p>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.</p>

<example>
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;
  }
}
</example>

<p>The <code>needsAuthentication</code> 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.</p>

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

</s1>

<s1 name="protectall" title="Protecting static files from viewing by anyone">

<p>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.</p>

<s2 title="Place files in WEB-INF">
<p>Place files in <var>WEB-INF</var> or a subdirectory of <var>WEB-INF</var>.  Any files in
<var>WEB-INF</var> or it's subdirectories will automatically be protected
from viewing.</p>
</s2>

<s2 title="Security constraint requiring role nobody">
<p>Use a security constraint that requires a <var>role</var> that nobody
will ever have.</p>

<example title="security-constraint to protect static files">
&lt;web-app&gt;
  ...
  &lt;!-- protect all .properties files --&gt;
  &lt;security-constraint&gt;
    &lt;web-resource-collection&gt;
      &lt;url-pattern&gt;*.properties&lt;/url-pattern&gt;
    &lt;/web-resource-collection&gt;
    &lt;auth-constraint role-name='nobody'/&gt;
  &lt;/security-constraint&gt;

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

<s2 title="A servlet that returns a 403 error">
<p>Use a simple servlet that returns a 403 error, which means
"Forbidden".  Resin provides the servlet <a href="javadoc|com.caucho.servlets.ErrorStatusServlet|"/> which is useful for
this:</p>

<example title="Using ErrorStatusServlet to protect static files">
&lt;web-app&gt;
  ...
  &lt;servlet&gt;
    &lt;servlet-name&gt;forbidden&lt;/servlet-name&gt;
    &lt;servlet-class&gt;com.caucho.servlets.ErrorStatusServlet&lt;/servlet-class&gt;
    &lt;init&gt;
      &lt;status-code&gt;403&lt;/status-code&gt;
    &lt;/init&gt;
  &lt;/servlet&gt;

  &lt;servlet-mapping url-pattern="*.properties" servlet-name="forbidden"/&gt;
  &lt;servlet-mapping url-pattern="/config/*" servlet-name="forbidden"/&gt;
  ...
&lt;/web-app&gt;
</example>

<p>Or you could implement your own servlet:</p>

<example title="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);
  }
}
</example>
</s2>

</s1>

<s1 name="aboutssl" title="What SSL provides">

<p>SSL provides two kinds of protection, <var>encryption</var> and <var>server
authentication</var>.</p>

<s2 title="Encryption">

<glossary title="public key">
A set of bytes used to <var>encrypt</var> data and <var>verify signatures</var>.
The key is public because it can be made available without a loss of security.
The public key can only be used for encryption; it cannot decrypt
anything.  A public key always has a corresponding <var>private key</var>.
</glossary>


<p>SSL provides encryption of the data traffic betweeen a client and a server.
When the traffic is encrypted, an interception of that traffic will not reveal
the contents because they have been encrypted - it will be unusable
nonsense.</p>

<glossary title="private key" type="sidebar-left">
A set of bytes used to <var>decrypt</var> data and <var>generate signatures</var>.
The key is private because it must be kept secret or there will be a loss of
security.  The private key is used for decryption of data that has been
encrypted with the corresponding <var>public key</var>.
</glossary>

<p>
SSL uses public key cryptography.  Public key cryptography is based upon a
pair of keys, the public key and the private key.  The public key is used to
encrypt the data.  Only the corresponding private key can successfully decrypt
the data.  
</p>

<p>
For example, when a browser connects to Resin, Resin provides the browser a
public key.  The browser uses the public key to encrypt the data, and Resin
uses the private key to decrypt the data.  For this reason, it is important that
you never allow anyone access to the private key, if the private key is
obtained by someone then they can use it to decrypt the data traffic. 
</p>

<p>Encryption is arguably the more important of the security meausures that SSL
provides.</p>

</s2> <!-- aboutssl/Encryption -->

<s2 title="Server Authentication">

<glossary title="certificate">
A combination of a <var>private key</var>, identity information (such as company
name), and a <var>signature</var> generated by a <var>signing authority</var>.