Security in Resin consists of four separate functions:
By using Resin's login support, applications can add security without writing an entire authentication library. If the predefined authentication methods, XML and database user lookup, are inadequate, Resin provides an API to write custom authentication code.
The easiest authenticator to understand is the XmlAuthenticator. It lets you put users and passwords directly in the configuration file. The following example uses "Basic" authentication for login. Basic authentication asks the browser to pop open a window prompting for a username and password. (Basic authentication is discouraged because it is not secure unless you use it with SSL, but it's the easiest example.) The only user defined here is "Harry Potter" and he has the password "quidditch". He also plays the "user" role.
In the above example, the <security-constraint> checks for authorization. Only users playing the "user" role can access the /users-only directory.
Selects the authentication method.
Configures authentication for forms. The login form has specific parameters that the servlet engine's login form processing understands. If the login succeeds, the user will see the original page. If it fails, she will see the error page.
The form itself must have the action. It must also have the parameters and . Optionally, it can also have and . gives the next page to display when login succeeds. allows Resin to send a persistent cookie to the user to make following login easier.
gives control to the user whether to generate a persistent cookie. It lets you implement the "remember me" button. By default, the authentication only lasts for a single session.
The following is an example of a servlet-standard login page:
Specifies a class to authenticate users. This Resin-specific option lets you control your authentication. You can either create your own custom authenticator, or use Resin's JdbcAuthenticator.
The authenticator is responsible for taking the username and password and returning a UserPrincipal if the username and password match.
Users wanting to implement an authenticator should look at the JavaDoc for com.caucho.http.security.ServletAuthenticator and com.caucho.http.security.AbstractAuthenticator. To protect your application from API changes, you should extend AbstractAuthenticator rather than implementing Authenticator directly.
The XmlAuthenticator (com.caucho.http.security.XmlAuthenticator), stores the authentication in either an xml file or in the configuration itself.
When configuring the XmlAuthenticator in the resin.conf (or web.xml), eachadds a new configured user. The value contains the username, password, and the roles the user plays.
Because the plain text passwords in the example above are a serious security issue, most sites will use the password-digest attribute described below to protect the passwords.
The passwords can be specified in a separate *.xml file. The password file looks like:
Sites should use password-digest to protect the passwords.
The JdbcAuthenticator (com.caucho.http.security.JdbcAuthenticator), asks a backend database for the password matching the user's name. It uses the DataSource specified by the resource-ref.option, or the JNDI by default. refers to a DataSource configured with
The following are the attributes for the JdbcAuthenticator:
Resin 2.0.4 adds the capability to store the digest of a password instead of the password itself. By using the password digest, the application can avoid storing the password in a form that someone can read.
Setting password-digest of any authenticator extending AbstractAuthenticator will create a digest of the password. The password-digest has two parts: the digest algorithm and the encoding format. "MD5-base64" is a typical digest format.
The authenticator will create a digest of the username and password. Since that digest is a byte array, it is then converted to a string.
Of course, storing the digest password take a bit more work. When the user registers, the application needs to compute the digest to store it. You can use the PasswordDigest class to do that.
Selects protected areas of the web site. Sites using authentication as an optional personalization feature will typically not use any security constraints.
Security constraints can also be custom classes.
Specifies a collection os areas of the web site.
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.
Requires that the remote address is in an IP network. ip-constraint is very useful for protecting administration resources to an internal network.
Restricts access to secure transports, i.e. SSL.
Restricts access to secure transports, i.e. SSL.
Defines a custom constraint. The custom constraint specifies awhich extends com.caucho.http.security.AbstractConstraint. Any elements use Bean introspection to initialize the 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 return an error page.
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.
The OpenSSL configuration has two tags <certificate-file> and <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.
The full set of parameters is in the port configuration.
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.
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.
Adding a Java security manager puts each web-app into a "sandbox" where Java limits their abilities.
The security manager is enabled by adding a security-manager tag in the resin.conf.
Sun's documentation is available at http://java.sun.com/j2se/1.4/docs/guide/security/index.html. In particular, the policy permissions and policy file syntax files are useful.
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 <classpath> from the <host> and <http-server> contexts.