Portlet Factory, Version 6.1.2
Overview: security methodologies
Maintaining a secure environment is critical when you deploy a Web application.
This topic discusses security within the context of the J2EE environment. The strategies and approaches described are designed to allow you to deploy an application in as secure a manner as possible while making use of the inherent security mechanisms provided by your server.
IBM® WebSphere Portlet Factory relies upon standards-based security mechanisms provided by the J2EE application and portal servers. Rather than using proprietary security mechanisms and adapting other external mechanisms, WebSphere Portlet Factory relies on J2EE application server mechanisms to provide security and to integrate with external security products.
WebSphere Portlet Factory security includes:
- The use of J2EE Deployment Descriptor (web.xml-based) Security Constraints and Security Roles.
- Optional use of callouts to third-party security systems (for auditing or additional custom authorization checks) on model requests. These are often implemented by onRequest handlers.
To protect your widgets from being accessed directly using a URL without the user having logged into a target server, put security constraints in your project WEB-INF/bin/deployment/standalone.web.xml template. The security constraints are set in the web.xml for the WAR, limiting access to folders of models (for example, /factory/* and one for yourmodels/*). After you deploy the WAR, you can use the WebSphere administrative console to navigate to your application and associate security role mappings with users and groups.
Benefits of J2EE security approach
WebSphere Portlet Factory enjoys several benefits from using standard J2EE security mechanisms. These benefits include:
- Better integration with what application servers and value added components provide and rely on. You can also more easily integrate a WebSphere Portlet Factory WebApp with other J2EE-based components.
- Better integration with other features of the application servers that rely on the server's authentication mechanisms and J2EE Application Roles by means of the EJB deployment descriptor and security constraints.
In general, application server tools are used to create and manage roles and to map those roles to users associated with the application server. (See the Java 2 Platform Enterprise Edition Specification for additional information about roles in a J2EE environment.)
The following semantics apply to J2EE application security used by WebSphere Portlet Factory:
- Authorization is based on URL path components
- URLs to Web applications include the folder hierarchy and model name
- Similarly protected models should be grouped under common sub-folders protected by security constraints
- Only protected (by security constraint) resources such as models and JSPs can retrieve security information from the application server servlet container (for example, user name, request, and isUserInRole().)
Parent topic: WebSphere Portlet Factory reference
- Security best practices
Review these security-related tips, tricks, and best practices for WebSphere Portlet Factory WebApp model-based deployments.
- Security trick: encourage closing the browser
Closing the browser window would not be acceptable behavior for most public web sites, as users typically browse from one site to another.
- Custom login pages
When using J2EE/Servlet-based Declarative Security with security constraints in the web.xml deployment descriptor, there are certain limitations in the current version of the J2EE/Servlet specs that you need to work within.
- Security trick: dummy JSP page
There is no standard way for a J2EE application to decide itself when to forward the user to a login page. Nor is there an easy way for an application to know where to send the request back to on successful authentication.
- Using dynamic cookies
All of your session and security related cookies should be dynamic cookies associated with a single browser session, and not persistent cookies (with a >0 lifetime) stored on disk.
- Gathering user information
WebSphere Portlet Factory allows you to use whatever custom user information you need (such as the full power of the user registry in use for each deployment scenario) rather than try to force use of a least common denominator by trying to map every possible third party user security/registration system into a common user profile.
- Logout – session cleanup
It is always a good idea to put a Logout button in an obvious place in your application to encourage users to log out when they are done, rather than just closing their browser and allowing their session data to persist until their session times out.
- Example application server security scenario
This is an application server security scenario.
- Security example – J2EE
The following example illustrates security implemented for a IBM WebSphere Portlet Factory web application composed of several WebApp models.
- Configuration Example – Login/Role
For requests to models under the above protected models, where a user is not already authenticated, the application server's servlet container will itself force the request to perform a login before sending the request on to the original URL destination (if authenticated and authorized based on the specified role(s)).
- Example WEB.XML security components
The following configuration information represents the security portions of the WEB-INF/web.xml J2EE Web Application Deployment Descriptor that ships with IBM WebSphere Portlet Factory 5.
Library | Support |