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
. TheCallback[]
array will be populated with theLTPATokenCallback
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. TheCallback[]
array will be populated with the following callback objects in the given order:LTPATokenCallback
IdentityTokenCallback
NameCallback
PasswordCallback
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());