Maintaining a secure environment is critical when you publish or export 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 publish 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 publish 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().)
Security best practices: wpf7
Review these security-related tips, tricks, and best practices for WebSphere Portlet Factory WebApp model-based publishing and exporting.
Security trick: encourage closing the browser: wpf7
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: wpf7
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: wpf7
There is no standard way for a J2EE application to decide itself when to forward the user to a login page.
Using dynamic cookies: wpf7
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: wpf7
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: wpf7
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: wpf7
This is an application server security scenario.
Security example J2EE: wpf7
The following example illustrates security implemented for a IBM WebSphere Portlet Factory web application composed of several WebApp models.
Configuration Example LoginRole: wpf7
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: wpf7
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.
Parent topic: Reference information: wpf7