Develop > Presentation layer > WebSphere Commerce integration with WebSphere Portal > Customize WebSphere Commerce Portal integration > Use the provided WebSphere Commerce MVCPortlet class (MVC style) > WebSphere Commerce Portal integration event handlers > WebSphere Commerce portlet action handler
Authentication callback handler object
Regardless of which authentication method the portlet chooses to use, the client library and WebSphere Commerce services should not be aware of the method when interacting with the portlet in the Portal environment. A callback handler is therefore used to generate an identity token for use in calling a WebSphere Commerce service client library.
The idea is to have the underlying service binding layer to process the single sign on request against the WebSphere Commerce server on behalf of the client without knowing the technical details. The service binding sets empty callback objects according to the portlet authentication configuration, into the callback handler, AuthenticationCallbackHandler, which implements the javax.security.auth.callback.CallbackHandler interface. Its handle() method handles all the required operations to obtain the identity token for use in the service binding layer. If authentication is successful, the callback array is populated with the following callback objects, depending on the authentication type defined in the portlet:
- LTPA
- When the authentication type is LTPA, this callback handler will retrieve the LTPA directly from the thread using the WAS API every time this callback handler is being called, and the LTPA will not be stored locally in the PortletSession. The Callback[] array will be populated with the LTPATokenCallback object.
- Basic Authentication, Simulated Single Sign On
- When the authentication type is Basic Authentication or Simulated Single Sign On, this callback handler tries to retrieve the Identity token from the portlet session if possible. If there is not one found and if the user is authenticated, then the handler will call out to the Business Context Service web service on the WebSphere Commerce side to perform the (single sign-on) authentication on behalf of the Portal user. Once authenticated successfully, an Identity token is obtained and it will be stored into the PortletSession for future usage. The Callback[] array will be populated with the following callback objects in the given order:
- LTPATokenCallback
- IdentityTokenCallback
- NameCallback
- PasswordCallback
An anonymous user can be one of the following two corresponding WebSphere Commerce users:
- Generic user
- This type of user does not have a session.
- Guest user
- This type of user has a temporary session which corresponds to a WebSphere Commerce guest user.
The callback handler also behaves slightly differently depending on the status of the user:
What determines whether the anonymous user is a generic user or a guest user is the session property for all portlet actions and renders used for rendering a page. If at least one of the portlet action or render used for rendering a page has the session property set to true, then a session will be created and the user automatically becomes a WebSphere Commerce guest user.
- Generic user
- Since no session is associated with this type of user, no identity token will be generated; that is all requests are stateless.
- Guest user
- Once a session is created for the anonymous user, the user automatically becomes a WebSphere Commerce guest user and a temporary guest user identity token is generated and stored in the portlet session to keep track of the corresponding WebSphere Commerce session.
If the credential plug-in configuration defines the authentication type to be Simulated SSO or Basic Authentication, then the user name and password are set into the PasswordCallback object.
In order to retrieve an existing authentication callback handler object from the portlet session, you can write the following code to call a special helper class using a contextKey
CallbackHandler callbackHandler = SessionHelper.getCallbackHandler(portletRequest, contextId);
A credential plug-in is one that helps generate the authentication callback handler mentioned above. It leverages the MVC plug-in framework so that you can specify a customized version instead. The credential plug-in must implement the PortletCredentialPlugIn interface which can be initialized and destroyed along with the WebSphere Commerce portlet. A default implementation has been provided, com.ibm.commerce.foundation.client.portal.services.MVCPortletCredentialService.
The following is an example of how to create the authentication callback using the MVCPortletCredentialService credential plug-in:
PortletCredentialPlugIn portletCredentialPlugIn = (PortletCredentialPlugIn) MVCPortletServiceRegistry.singleton().getPortletService(iPortlet.getPortletName(), PortletPlugIn.TYPE_CREDENTIAL); CallbackHandler callbackHandler = portletCredentialPlugIn.getCallbackHandler(getActionRequest());
The following is an example of how to call the client library, passing the business context object and authentication callback as arguments:
CatalogFacadeClient client = new CatalogFacadeClient(businessContext, callbackHandler); CatalogType catalog = client.findCatalogByCatEntryId(new Long("10001").longValue());