Portlet Factory, Version 6.1.2

 

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.

In particular, the J2EE Servlet specification (and various implementations of it), appears to assume one web application per deployed WAR (web archive file), such as the one WebSphere Portlet Factory is installed as. (The WAR root is the folder just above WEB-INF, in your installation, where web.xml is located).

As a result of this, each WAR/web.xml deployment descriptor limits you to exactly one login-config block, which configures how login should be performed for that particular J2EE Web Application.

If you want one Web application to login using a particular form, and another to login via HTTP Basic Auth or Certificates (such as you might do for authenticating during a SOAP service call), you need to have each web application in a separate WAR (web application archive as defined by the J2EE specs). In the case of the WebSphere Portlet Factory WAR, that would mean two installations of the WebSphere Portlet Factory WAR, each hosting one of those above mentioned applications with different types of login requirements.

For example, WebSphere Portlet Factory installs the following default login-config: 

<login-config id="LoginConfig_1">
<!-- Login configuration to use if security constraint forces requestor to login before proceeding to a protected URL. To change to HTTP Basic Auth, eg for use with SOAP services, change FORM to BASIC in the <auth-method> element below.
-->
<auth-method>FORM</auth-method>
<realm-name>WebAppAuthentication</realm-name>
<form-login-config id="FormLoginConfig_1">
<form-login-page>/factory/login/login.jsp</form-login-page>
<form-error-page>/factory/login/error.jsp</form-error-page>
</form-login-config>
</login-config>

To change your login mechanism for a Web application to HTTP Basic Auth, you would change the above <auth-method> value from FORM to BASIC.

If you have multiple WebSphere Portlet Factory WebApp model-based applications within one J2EE Web Application Archive (WAR), that both require FORM based login, then they will all be redirected by the application server to the configured login URL (/factory/login/login.jsp in the above example, which is relative to the application context of the installed enterprise application. For example, http://server:port/myproject/factory/login/login.jsp if the application context is "myproject").

However, just because all form login requests go to the same URL, does not mean that the look and feel of that form-based login page must be the same for all WebSphere Portlet Factory model-based WebApps running in that WAR as defined by this web.xml file. The login page in this case is a JSP page, and JSP pages are dynamic by design. Thus you can customize the look and feel of the login page as needed.

The default login.jsp shipped with WebSphere Portlet Factory has just such flexibility built into it. You can use this page to customize form-based login pages. The entire login.jsp page contents are shown below: 

< -- See if a public WebApp or JSP set a custom login page before the user hit a protected resource -->
< String customLoginPage = (String)session.getAttribute("bowstreet.security.login.custom"); if ((customLoginPage == null) || (customLoginPage.length()==0)) customLoginPage = "default_login.jsp";
%>
<jsp:include page="<=customLoginPage>" flush="true" />

That login.jsp does not look much like a login page, because it really is not "the" login form page. Instead, it is a wrapper page that includes the actual login page look and feel. If a public part of one of your WebSphere Portlet Factory model-based WebApps has run first (before hitting a URL protected by security constraint), and it has put a login page filename path in your HTTP Session (as in the example below), then this login.jsp wrapper will use that login page for the actual login form HTML returned to the browser. If no such setting has been put in your session, then the login.jsp wrapper will include the default login page in default_login.jsp in its response to the browser, which contains the default WebSphere Portlet Factory look and feel for login.

The sample "public" model at WEB-INF/models/factory/samples/login/sampleLoginAppMainEntry.model provides an example of the public application portion of the above described mechanism. It puts the path name to a custom login form in the user's session with the well known key: "bowstreet.security.login.custom" which the above login.jsp looks for. This public model then displays a page with a button that will submit a request to the protected (by security constraint) model that is located in: WEB-INF/models/factory/samples/protectedSamples/sampleLoginAppProtectedPart.model.

Because /webengine/factory/samples/protectedSamples/* URL is protected by security constraint, you will be forced to log in (by the application server) and match the role in that security constraint, before being passed off to this protected model. In this example, the protected model does nothing but display a page stating that you should have been logged in before getting to that point.

To access the sample, use an account associated with one of the roles (for example, FactoryAdministrators) in the samples/protectedSamples security constraint in the WEB-INF/web.xml deployment descriptor. You should have mapped users/groups to roles during the installation/configuration process as described in the WebSphere Portlet Factory 5 Installation Guide for your AppServer.

Here is the Java code that the public model (sampleLoginAppMainEntry.model) calls, so that if/when you are redirected to login by security constraint, the login.jsp will be able to give you a custom looking login page rather than the default. 

// Get a reference to the session javax.servlet.http.HttpSession session = webAppAccess.getHttpServletRequest().getSession(); session.setAttribute("bowstreet.security.login.custom", "/factory/login/my_custom_login_sample.jsp");

When the login.jsp page (shown earlier in this section) checks the session, it finds this custom path to a login page and includes this custom login page in its response page to the browser, rather than default_login.jsp.

If the above customization tricks seem like too much work for your particular scenario requirements, you can always fall back to what the J2EE/Servlet specs appear to have intended, which is one Web application per WAR and deployment descriptor (web.xml). Using this approach you completely customize the login-config URL and login page for each application, and then deploy each application in a separate EAR/WAR (each with their own web.xml and application archive installation) on your application server(s).

Parent topic: Overview: security methodologies

Library | Support |