Monday, 29 August 2011

Login Service SPI

The public login portlet service introduced with WebSphere Portal V6.0.1 (interface can be used to trigger a form-based login to WebSphere Portal from any portlet .This service is useful in a couple of different scenarios in which the following conditions apply:
·      It is necessary to enhance the login portlet by additional elements, for example, a custom form, additional input elements, or enhanced portlet functionality.
  • The user input or parts of it need to be modified by some logic before being passed to the actual login.
  • You want to propagate information from the user interface to the actual login, for example, in the object passed on to the Java™ Authentication and Authorization Service (JAAS) login or the login context that is passed to the ExplicitLoginFilter elements introduced with WebSphere Portal V6.1
  • You want to influence the login portlet’s behavior in reaction to particular errors that might occur during the login, for example, a redirect operation to a dedicated page to change the password after the login failed, indicating that the password expired. 
Operation of Login Service

An instance of the is retrieved for FavouriteLogin Portlet request and response pair using the interface, which can be looked up using Java Naming and Directory Interface (JNDI) once (for example, during portlet initialization).The service provides one method to trigger a login that takes the user ID, password, a mandatory java.util.Map object that holds context information, and an optional prefilled object. 

The login method defines a couple of exceptions to distinguish several error conditions that can cause the login to fail and might be handled appropriately in the portlet. Additionally, the interface defines a constant DO_RESUME_SESSION_KEY to be used as a key to store a java.lang.Boolean object to indicate whether the portal should perform a session resume. If an error occurs during login, the portlet renders the view with the login form again, additionally displaying the message of the error on the top.If there is no error in login, user is authenticated and redirected to protected page.(from /portal to /myportal)

For redirecting to a custom page after logging(using login service),please refer to my article.

Download the code

Sunday, 28 August 2011

Client-side and server-side page rendering modes in Page Bulider Theme

Client-side mode
    In client-side mode the following applies:
    • Page changes occur without a browser full page refresh. Upon a user request a SWITCH_PAGE client-side event is fired. This triggers the update of the page navigation, and the contents of the new page are loaded and replace the content of the prior page.
    • Interaction with portlets and widgets updates only the affected portlet or widget, and possibly others as a result of wiring. Portlets are rendered as iWidgets by means of an iWidget Wrapper.
    • The implementation and programming model for client-side mode is provided by the Mashups Enabler common component, and public builder events.
Server-side mode

In server-side mode the following applies:
  • Page changes cause a browser full page refresh.
  • Interactions with portlets result in a browser full page refresh.
  • However, iWidgets are rendered and interact within the page just as in client-side mode. 
Theme adjustment  to Modes:
To render the portal theme, the same theme elements are used in both rendering modes. In general, you can write navigation iWidgets to fire a SWITCH_PAGE event. The internal JavaScript NavigationController of the theme determines the current rendering mode of the page and processes the event appropriately.

Thursday, 25 August 2011

Develop Custom Authentication filters

Types of  authentication filter
  •   Explicit login: This is a login by user name and password as represented by the For example, this can be a login by using the login portlet or the login URL.
  •   Implicit login: For example, this can be when a user is already authenticated by WAS, but not yet to Portal. This is represented by the interface
  •  Explicit logout: This means that the user triggers a logout action directly, for example by clicking the Logout button in the user interface, interface
  •  Implicit logout: For example, this can be after a session timeout, or if an authenticated user accesses a public page, or if the user navigates to a virtual portal without being member of the associated user realm. This is represented by the interface
  •   Session Timeout: This is called immediately after an idle timeout of the user session occurred. This is represented by the interface
  •  Session Validation: This is called for every request before actions are triggered and the page is rendered. This is represented by the interface

  • Steps to be followed to Create Custom Filter
    To create a custom authentication filter, follow these steps:
    1. Implement one of the six available filter interfaces.
    2. Export your implementation as a JAR onto the Portal class path, for example, portalServer_root/shared/app.
    3. Complete the following steps to register the filter in WebSphere Application Server:
    a.  Login to the WebSphere Application Server Integrated Solutions Console as an Administrator.
    b. Select Resources->Resource Environment Providers->WPAuthenticationService->Custom properties
    c. Add a new entry to register your custom filter.
    4. Restart WebSphere Portal for the changes to take effect.

    Creating Custom ExplicitLoginFilter
    import javax.servlet.http.HttpServletRequest;
    import javax.servlet.http.HttpServletResponse;
    public class TestExplictFilter implements ExplicitLoginFilter{

          public void destroy() {
                // TODO Auto-generated method stub

          public void init(SecurityFilterConfig arg0)
                      throws SecurityFilterInitException {
                // TODO Auto-generated method stub

        public void login(HttpServletRequest req,
                HttpServletResponse resp,
                String userID,
                char[] password,
                FilterChainContext portalLoginContext,
                Subject subject,
                String realm,
                ExplicitLoginFilterChain chain)
                LoginException {
                 // first call the next filter in the chain to pass on the login information
            try {
                chain.login(req, resp, userID, password, portalLoginContext, subject, realm);
                } catch ( e) {
                      // TODO Auto-generated catch block
                // TODO Auto-generated method stub


    Registering the service

             Name: login.explicit.filterchain
           Value: com.sample.login.filter.TestExplictFilter
              After Login using  Login Portlet:

 Download the code