Security considerations
When leveraging IBM® WebSphere® sMash security, consider following best practices such as configuring security rules, requiring SSL for a set of resources, and avoiding caching secured resources.
Best practices for configuring security rules
The recommended URI pattern is /<prefix>(/.*)?. For example, a pattern of
/foo(/.*)? would match requests for /foo, /foo/ and
/foo/bar/index.html. Using a pattern that is based on prefixes prevents clients
from circumventing security rules by adding pathInfo to the end of a request.
Protecting files that are served under the default file serving rules
require special attention. If you want to protect default files you must protect the directory.
For example, if you do not want /foo/index.html served, be sure to protect
/foo/. This is accomplished using the prefix-based rules.
Set SSL requirements on resources
To require HTTPS access to a resource, create a requireSSL=true rule. For example, the
following rule protects the resource with basic authentication while also requiring the connection to be SSL:
## enable security for the application
@include "security/enableSecurity.config"
@include "security/requireSSL.config"{
"conditions": "/request/path =~ /employees(/.*)?"
}
@include "security/basicAuthentication.config"{
"conditions": "/request/path =~ /employees(/.*)?"
}
The SSL requirement can be combined with requirements for authentication, authorization or both, by
adding the requireSSL.config template. It can also be used where there are no other
security requirements. For example, the same resource in the previous example can be designated as
requiring SSL but not be protected as shown in the following example:
## enable security for the application
@include "security/enableSecurity.config"
@include "security/requireSSL.config"{
"conditions" : "/request/path =~/employees(/.*)?",
"requireSSL": true
}
If configure a resource to requires SSL to access the resource, a 403 (Access Forbidden) status code is returned to the client.
Limiting caching secured resources
To limit the caching of secured resources on the client, WebSphere sMash security sets the cache-control header for all secured resources and the associated login forms (OpenID, Form-based Login, Single Sign-On) that are provided as part of the WebSphere sMash security model.
The default cache-control header value is "must-revalidate","max-age=0","private".
In the following example the default cache-control value is set and will override the default setting:
# max-age/must-revalidate can be dropped if there are only 1.1 # caches as it would improve cacheability /config/security/cacheControl = ["must-revalidate","max-age=0","private"]
Custom security handlers that override the secure event or provide a custom security implementation for obtaining a user's credentials must handle the cache-control header themselves. To add this cache-control header programmatically, the following API is provided.
zero.core.security.TokenService.setCacheControlHeader();
Fine-granular control of cross-site request forgery protection
WebSphere sMash allows you to protect against cross-site request forgery.
Specify csrfProtect to gain additional control over how the protection is handled.
Cross-site request forgery protection is provided in the zero.acf module. This module
has reasonable defaults and in most cases it is not necessary to provide any further configuration.
See the Protection against cross-site request forgery (CSRF) attacks document for more information.
