WCS Authentication model provides multiple extension points to implement custom logic, in this blog we will run through few key commands of WCS authentication model, before we can jump start, make sure you read and understand WebSphere commerce authentication model on infocenter.

During logon process, the authentication command will read and apply the authentication policy defined for your store, for instance you can define a password or account lockout policy for your store, and this will be executed during login process.

LoginCmdImpl
This is the default implementation which is available Out of the box in case you decide to maintain the complete user base in WCS member subsystem tables, this is probably the most simplest scenarios in low volume commerce sites. in most cases the Organization might have an existing LDAP directory service to maintain user data for both internal and external users.

In case of LDAP mode, the OOB Login command will not check the WCS Account policies, your best bet would be to overwrite the implementation of isAccountDisabled() method in your extended Logon command implementation, you will also overwrite the AccountLockoutPolicyCmdImpl default implementation to make sure the Account Lockout policy is checked in LDAP mode, the default implementation ofAccountLockoutPolicyCmdImpl would just skip the logic for LDAP mode.

Sample extension logic

public class MyCompanyLogonCmdImpl extends LogonCmdImpl {

    public void performExecute() throws ECException {
        super.performExecute(); // This executes the default implementation
        // perform any additional custom logon processing logic.
    }
}

Assuming 10051 is your store asset store id, you would make following entry in cmdreg table so that WCS will pickup your custom implementation of logon command for your store.

insert into cmdreg (storeent_id, interfacename, classname, target) values
(10051,'com.ibm.commerce.security.commands.LogonCmd','com.ibm.commerce.security.sample.MyCustomLogonCmdImpl','Local')

Techtip: Since you are overwriting an existing command, you don't have to load acppolicy

LDAPAuthenticationCmdImpl
This is the default implementation of LDAP authentication command which is invoked by Login command in case your store is configured for LDAP based autentication.

NOTE: As of V7, WMMAuthenticationCmd and WMMAuthenticationCmdImpl has been deprecated and replaced by LDAPAuthenticationCmd and LDAPAuthenticationCmdImpl

BusinessContextServiceLogonCmdImpl

Use this command in case you do not want to migrate the user resources from guest state to logged in state, for instance default behaviour of Logon command is to merge the anonymous cart content with logged in user cart content during successful login.

MigrateUserEntriesCmd

The default implementation of this TASK command migrates some of the important user data from guest to logged in state. E.g. Addresses, Current Orders, Interest Items, Order Items, Orders, and Order Templates
This Task command is called by LoginCmd during login process.Any custom logic for data migration from guest to logged in state can be hooked in this TASK command.

Let us see few use cases, case 1: you would like to hook additional migration tasks on top of existing logic

MigrateMyCompanyUserEntriesCmdImpl
public void performExecute()
        throws ECException
    {
        super.performExecute(); // This will execute all of the migration task associated with the default implementaion
//place for custom calls to migrate data.

    }

Case 2: You just want to overwrite one of the default implementation's of MigrateUserEntriesCmd Impl
methods, like migrateOrders()

public class MyCompanyMigrateUserEntriesCmdImpl extends MigrateUserEntriesCmdImpl
    implements MigrateUserEntriesCmd

    public MyCompanyMigrateUserEntriesCmdImpl ()
    {
    }

public void migrateOrders(UserAccessBean abOldUser, UserAccessBean abNewUser)
        throws ECException
    {
        //write your custom logic to migrate guest to logged in user order.

    }

}

insert into cmdreg (storeent_id, interfacename, classname, target) values
(10051,'com.ibm.commerce.security.commands.MigrateUserEntriesCmd','com.ibm.commerce.security.sample.MigrateMyCompanyUserEntriesCmdImpl','Local')

LogoffCmdImpl

Extend this command to implement any custom logic that needs to be applied when user logs off from the site, this is ideally a good place to clean up any custom session level, cookie information that you might have stored in logged in state.

public class MyCompanyLogoffCmdImpl extends LogoffCmdImpl implements LogoffCmd {

public void performExecute() throws ECException {
// Implement your custom loggoff logic.
}

}

SessionListener
What if user never clicks on logoff and you still need the logoff logic to be executed, in such cases it is a good idea to have a session listener, the listener will automatically listen to session timeout.

public class MyStoreSessionListener implements HttpSessionListener {

    @Override
    public void sessionCreated(HttpSessionEvent arg0) {
        // TODO Auto-generated method stub
        System.out.println("HttpSession object has been created");
    }

    @Override
    public void sessionDestroyed(HttpSessionEvent se) {
        // TODO Auto-generated method stub
        System.out.println("HttpSession object has been removed");
    }

}

Make following entry in web.xml

<listener>
    <listener-class>com.ibm.commerce.listener.MyStoreSessionListener</listener-class>
</listener>

Member subsystem in WCS provides simple to advanced options for configuration, you have multiple extension points to hook your custom logic, refer to following IBM materials for some additional details around member subsystem configuration.

Federating multiple authentication system
Federating two LDAP servers with WCS

All about WCS Logon and Logoff commands