Portlet Factory, Version 6.1.2

 

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.

However, a possible work around for this lack of capability might include:

Creating a dummy JSP page

This page does nothing but redirect to where you typically want to go after a successful login either hardwired or passed as input, for example, a portal's main page. (See the following file for an example: installed-root/factory/webapp/auhtorizationloginhandler.jsp and also the associated security constraint in the web.xml file.)

Making that dummy page a protected resource using a security constraint

<security-constraint id="SecurityConstraint_3">
<!-- Back door means of redirecting someone to a protected page
(i.e., the JSP listed in the url pattern here) to force them to login, even if your app is mostly public. The OPTIONAL J2EE Role based authorization handler may also force a user to this protected page if you inadvertently forgot to protect a model with a security constraint, but still specified optional model security property based list of roles via the Designer. View the source of this JSP page to see how it works and what it does after the user has been logged in and gets to this page, which should do nothing other than redirect you to where you were trying to go before.
-->
<web-resource-collection id="WebResourceCollection_3">
<web-resource-name>ForceLogin</web-resource-name>
<url-pattern>/factory/webapp/authorizationloginhandler.jsp</url-pattern>
</web-resource-collection>
<auth-constraint id="AuthConstraint_3">
<description>Roles allowed through forced login redirect page (typically all roles)</description>
<role-name>FactoryAdministrators</role-name>
<role-name>AllAuthenticatedUsers</role-name>
</auth-constraint>
</security-constraint>

  • When you want a user to log in and then go to the main public entry page (or to the page you specify as a request parameter to the dummy JSP page), send them to the protected dummy page. Since this page is protected, the application server Servlet Container will force the login at that point and send the user back to the dummy page. The dummy page can then forward the user on as appropriate.
This trick allows the main model/page to support both unauthenticated requests (unprotected with anonymous access allowed) and authenticated users. It also allows your application to decide when the user should log in before going to that page, instead of the having the application server always forcing log in, as would be the case if that main model/page were protected by a Security Constraint.

Note: You should still attempt to retrieve only user information (user name, role) from the J2EE servlet APIs, from resources (models, JSPs) protected by security constraints.

In most cases, you can use Security Constraints to protect various models and pages and automatically force login. Doing so avoids the need for tricks such as the one described above. This information is provided to give you ideas about how you might use such tricks to meet particular application requirements not anticipated or supported by J2EE Declarative Security Constraints.

Parent topic: Overview: security methodologies

Library | Support |