Customized authentication - overriding "getUserPrincipal()"

["Morten S. Mortensen" <mo...@tietoenator.com>]

Hi all,

I am in the process of testing some custom authentication schemes of my own. One thing, I would like, is to have "request.getUserPrincipal()" and "request.getAuthType()" return what I tell the request to return.

The "usual" way to grab and manipulate things is to write a filter (or servlet), which wraps the incoming request and/or response and sends the wrapped versions down the filter-chain. One should suspect, that e.g. a wrapping of the request ends up in the request-objects accessible within JSP (possible wrapped again multiple times, depending upon the implementation of the engine) - so if I override "getUserPrincipal()" and "getAuthType()" and add a couple of setters "setUserPrincipal()" and "setAuthType()", I can control the result of "request.getUserPrincipal().getName()" and "request.getAuthType()".

This I have done.

Actually I created a kind of "plug-in"-object in the form of the interface shown below; it is supposed to include "isUserInRole()", too. The specializations of this interface have equivalent methods for setting the content to be returned. This "IdentityResource" plugs into the type of request-wrapper, which I create in a filter and use to invoke the filter-chain (of course a specialization of "javax.servlet.http.HttpServletRequestWrapper").

*Apparently*, somewhere between my filter-chain - which implements the custom authentication scheme and wraps the request before invoking the filter-chain - and the actual JSP-pages, which I use as a test, the result og "getAuthType()" and "getUserPrincipal()" is lost; the two methods return 'null'.

This is somewhat of a disappointment.

Since I suspect, that Tomcat does something with the request in between the filter-chain and the JSP-page, I have looked a bit at the types. On the "main JSP page", which I invoke, the request is of type -
"org.apache.coyote.tomcat4.CoyoteRequestFacade"
- and on a sub-page included from the main page with <jsp:include>, the request is of type -
"org.apache.catalina.core.ApplicationHttpRequest".
This has made me take a look at some of the source-code for this, but I can not find anything suspect, except that the top appears to.... not wrap the original request, but ends up in kind of a value-object...

Does something mess with the request before I hit the JSP-page-servlet-thingy?
This realm-plugin-facility, which Tomcat has built in - it does not touch the request-object passed between filters and JSP-page-servlets?

Somehow it does not work. Maybe I have screwed something up in my code, but after a lot of investigation, I do not thing this is the case.


Anyone care to comment? 

Who knows some details?

Anyone have tried something similar?


(yes, I now that the subject of "custom authentication schemes" within Servlets has been discussed, but postponed - but the construction, I try, should never the less be possible, if wrapping is done consistently)

     ?   ?   ?

Regards,
Morten Sabroe Mortensen 


     -----

/*** FILE "IdentityResource.java" *********************************************/

/******************************************************************************/
/**                                                                          **/
/**   2003-10-28   Morten Sabroe Mortensen.                                  **/
/**                                                                          **/
/******************************************************************************/

/*
 * $Log$
 */

package dk.tefs.J2EE.servlet.resource.http.identity;

import java.security.*;
import java.util.*;

/*** IdentityResource: ********************************************************/

/**
 * Identification of a authenticated user.
 *
 * @author <a href="mailto:Morten.Mortensen@TietoEnator.com"
 *         >Morten Sabroe Mortensen</a>
 * @version 1.0
 */
public interface IdentityResource
{
  /**
   * Gets the name of the authentication scheme used to protect 
   * the requested resource.
   * @see javax.servlet.http.HttpServletRequest#getAuthType
   * @return Name of authentication scheme.
   */
  String getAuthType();

  /**
   * Indicates, whether the authenticated user is included in 
   * a specified logical "role".
   * @see javax.servlet.http.HttpServletRequest#isUserInRole
   * @param role Logical role to get indication for.
   * @return Indicates, if the role indicates the authenticated user.
   */
  boolean isUserInRole(String role);

  /**
   * Gets a representation of the authenticated user, if any.
   * If the user has not been authenticated,
   * this return <code>null</code>.
   * @see javax.servlet.http.HttpServletRequest#getUserPrincipal
   * @return Representation of the authenticated user.
   */
  Principal getUserPrincipal();

  /**
   * Gets the name of the authenticated user, if any.
   * @see javax.servlet.http.HttpServletRequest#getRemoteUser
   * @return Name of authenticated user.
   */
  String getRemoteUser();
}

/******** "IdentityResource.java" *********************************************/

     -----

Fragment of "HttpServletRequestWrapper"-instance used to invoke filter-chain:

  /**
   * Wrapped request.
   */
  protected HttpServletRequest request;

  /**
   * Alternative identity-resource.
   */
  private IdentityResource identity;

  /**
   * Sets the identity-resource.
   * @param identity Identity-resource.
   */
  public void setIdentityResource(IdentityResource identity)
  {
    this.identity=identity;
  }

  /**
   * 
   */
  public Principal getUserPrincipal()
  {
    Principal res=null;

    {
      if (identity!=null)
      {
        res=identity.getUserPrincipal();
      }
      else
      {
        res=request.getUserPrincipal();
        //Note: It does a difference if 'super' or 'request' is called here!
      }
    }

    return res;
  }

     -----

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org