security.xtp

解压在c盘

<s2 name='authorization' title='Authorization (security-constraint)'>

<s3 title='security-constraint'>
<p>Selects protected areas of the web site.  Sites using
authentication as an optional personalization feature will typically
not use any security constraints.</p>

<p>Security constraints can also be custom classes.</p>

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

<s3 title='web-resource-collection'>
<p>Specifies a collection os areas of the web site.</p>

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

<s3 title='auth-constraint'>
<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>
<tr><td>role-name<td>Roles which are allowed to access the resource.
</deftable>

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

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

</s3>

<s3 title='ip-constraint' version='2.0.6'>
<p>Requires that the remote address is in an IP network.
ip-constraint is very useful for protecting administration resources
to an internal network.</p>

<example title='Admin pages allowed in 192.168.17.0/24'>
&lt;security-constraint>
  &lt;ip-constraint>192.168.17.0/24&lt;/ip-constraint>

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

</s3>

<s3 title='user-data-constraint'>
<p>Restricts access to secure transports, i.e. SSL.</p>

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

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

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

</s3>

<s3 title='transport-guarantee'>
<p>Restricts access to secure transports, i.e. SSL.</p>
</s3>

<s3 title='constraint' version='Resin 2.0.1'>
<p>Defines a custom constraint.  The custom constraint specifies
a <var/&lt;class-name>/> which extends
com.caucho.http.security.AbstractConstraint.  Any <var/init-param/>
elements use Bean introspection to initialize the constraint.</p>

<example>
...
&lt;security-constraint>
  &lt;constraint>
    &lt;class-name>qa.CustomSecurity&lt;/class-name>
    &lt;init-param foo='ok'/>
  &lt;/constraint>
  &lt;web-resource-collection url-pattern='/*'/>
&lt;/security-constraint>
...
</example>

</s3>

<s3 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 return an
error page.</p>

<example>
package qa;

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

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

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

  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>

</s3>

</s2>

<s2 name="encryption" title="Encryption (SSL)">

<s3 title="OpenSSL">

<p>The easiest way to add SSL support is to compile the JNI
libraries and use OpenSSL
(not available on Windows.)  OpenSSL is the same SSL implementation
that Apache's mod_ssl uses.</p>

<p>The OpenSSL configuration has two tags &lt;certificate-file> and
&lt;certificate-key-file>.  These correspond exactly to mod_ssl's
SSLCertificateFile and SSLCertificateKeyFile.  So you can use the same
certificates (and documentation) from mod_ssl.
</p>

<p>The full set of parameters is in the <a href="port-config.xtp#ssl">port configuration.</a>

<ol>
<li>Create a private key for the server:
<example>
unix> openssl genrsa -des3 -out gryffindor.key 1024
</example>
<li>Create a request for the the certificate to be signed:
<example>
unix> openssl req -new -key gryffindor.key -out gryffindor.csr
</example>
<li>Send the CSR to a certificate signer (CA).  You'll use the
instructions for Apache because the certificates are identical.
Some commercial signers include:
<ul>
<li><a href="http://digitalid.verisign.com/server/apacheNotice.htm">Verisign</a>
<li><a href="http://www.thawte.com/certs/server/request.html">Thawte
Consulting</a>
</ul>
<li>You'll receive a <em>gryffindor.crt</em> file.
<li>Configure Resin to use the files:
<example>
...
&lt;http port='443'>
  &lt;ssl/>
  &lt;certificate-file>/opt/ssl/keys/gryffindor.crt&lt;/certificate-file>
  &lt;certificate-key-file>/opt/ssl/keys/gryffindor.key&lt;/certificate-key-file>
  &lt;key-store-password>password&lt;/key-store-password>
&lt;/http>
</example>
</ol>

</s3>

</s2>

<s2 name="security-manager" title="Security Manager">

<p>In ISP environments, it's important that each user have 
restricted permissions to use the server.  Normally, the
web server will be run as a non-root user so the users can't
read system files, but that user will still have read access.</p>

<p>Don't use a security manager if you're not in an ISP environment.
There's no need for it and the security manager does slow the server
down somewhat.</p>

<p>Adding a Java security manager puts each web-app into a
"sandbox" where Java limits their abilities.</p>

<p>The security manager is enabled by adding a <a
href="resin-config.xtp">security-manager</a> tag in the resin.conf.</p>

<p>Sun's documentation is available at
<a href="http://java.sun.com/j2se/1.4/docs/guide/security/index.html">
http://java.sun.com/j2se/1.4/docs/guide/security/index.html</a>.
In particular, the <a href="http://java.sun.com/j2se/1.4/docs/guide/security/permissions.html">policy
permissions</a> and <a
href="http://java.sun.com/j2se/1.4/docs/guide/security/PolicyFiles.html">policy
file syntax</a> files are useful.</p>

<p>Each web-app automatically has permissions to read, write and
delete any file under the web-app's directory, including WEB-INF.  It
also has read permission for the classpath, including &lt;classpath>
from the &lt;host> and &lt;http-server> contexts.</p>

<example title="sample java.policy">
#
# Permissions allowed for everyone.
#
grant {
  permission java.util.PropertyPermission "*", "read";
  permission java.lang.RuntimePermission "accessClassInPackage.*";
  permission java.net.SocketPermission "mysql.myhost.com:3306" "connect";
  permission java.io.FilePermission "/opt/resin/xsl/*", "read";
};

#
# Give the system and Resin classes all permissions
#
grant codeBase "file:${resin.home}/lib/-" {
	permission java.security.AllPermission;
};

grant codeBase "file:${java.home}/lib/-" {
	permission java.security.AllPermission;
};

grant codeBase "file:${java.home}/jre/lib/-" {
	permission java.security.AllPermission;
};

#
# Give a specific web-app additional permissions.
#
grant codeBase "file:/opt/web/webapps/ejb/WEB-INF/-" {
	permission java.io.FilePermission "/opt/web/doc/*", "read";
};
</example>

</s2>

</s1>