Java Mailing List Archive

http://www.junlu.com/

Home » Home (12/2007) » Tomcat Users »

Customized authentication - overriding "getUserPrincipal()"

Morten S. Mortensen

2004-02-03



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@(protected)"
*      >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@(protected)
For additional commands, e-mail: tomcat-user-help@(protected)


©2008 junlu.com - Jax Systems, LLC, U.S.A.