I am implementing an auth handler for OpenID.

I have started with the wm_custAuth legacy portlet sample and have successfully got it into Designer and deployed and registered on MWS.

I am now in the process of implementing the OpenID4Java relying party code and find that I need the HttpServletResponse object. Is there anyway to get the response object from within the handler?

This is on MWS 8.2.

The response object is needed due to the federated nature of the authentication mechanism. Basically, the initial request is bounced to an OpenID server url that performs the token extraction, validation and login if the session is invalid. It then returns to a url specified in the original request for the application authentication to be completed.

Getting the second phase of the authentication to work is fairly straight forward, however, the first phase cannot be done as the response object is missing.

You can get the HttpServletResponse with this:

PortalServlet.getCurrentResponse()

However, an AuthHandler doesn’t have any control (or it shouldn’t) on how to process the request. I think for the initial redirect you should create a Filter that checks to see if you need to redirect the request, and then when you have gathered the proper credentials / information use the custom Auth Handler to fill in the AuthInfo.

Hope this helps,
–mark

Mark,

Are you suggesting to implement the filter within the custom auth context or on the overal portal context?

With OpenID, the idea is that the target application is very loosely coupled with the identity provider. At the time that the auth request is made on MWS, we do not know anything about the token that the browser has.

Essentially, this means that every auth request requires a redirect.

What happens is that if the idp verifies the token and the session is valid, the browser is redirected to a url that is provided as part of the request. This is where the MWS auth handler will then read the user information and fill in the AuthInfo object.

You don’t want to do this if the user is logged in, so using a filter could work provided if it is only activated when MWS really is asking for authentication (which I assume when the auth handler is called that is what MWS is asking).

As there is scarce documentation on the authentication mechanism of MWS, are you able to provide a url for a filter that would only be matched when an authentication request is initiated?

You’re filter will need to be intelligent enough to decide whether the user is already authenticated or not. Here’s a code sample that might help:

    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
if (!(request instanceof HttpServletRequest)) {
chain.doFilter(request, response);
}

//get auth info
HttpServletRequest httpServletRequest = (HttpServletRequest) request;
HttpServletResponse httpServletResponse = (HttpServletResponse) response;
IPrincipalData principalData = com.webmethods.portal.bizPolicy.impl.ContextFactory.acquireContext(request);
if (principalData != null && !principalData .isAuthenticated()) {
//perform redirect logic here
}

chain.doFilter(request, response);
}

You can look up the java docs for IPrincipalData and the IContext on the MWS javadocs here: http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/wmsuite8-2_ga/My_webMethods/8-2-SP1_CAF_and_MWS_Java_API_Reference/index.html

Regards,
–mark