HttpServletRequest.getRemoteUser() vs HttpServletRequest.getUserPrincipal().getName()

Question

These two seem to be doing the same things. Can anyone explain the main difference between the two? When would you use one vs the other?

HttpServletRequest.getRemoteU

Answer 1

A bit related issue:

People converting older IBM Portlet API code to JSR168 one had to change PortletRequest to HttpServletRequest in some method parameters, but then from WPS6.1 and up they can't cast that to PortletRequest (it doesn't implement the respective interface anymore as it seems) and if they call "getRemoteUser" directly on the HttpServletRequest they get back null (some say a workarround is to enable application security option in WAS [WebSphere Application Server], others say more security-related markup is needed in web.xml)

A workarround seems to be to use PUMA, but of course that is IBM WebSphere specific. Probably at other Portlet Containers there are other vendor-specific workarrounds if one finds that getRemoteUser always returns null (judging from other replies then getUserPrincipal().getName() also returns null if getRemoteUser is implemented as just a shortcut to that one).

BTW, the PUMA code I mention above is here, since it's a bit hard to find what works in WPS6.1+:

import com.ibm.portal.portlet.service.PortletServiceHome;
import com.ibm.portal.um.*;
import com.ibm.portal.um.exceptions.PumaException;
import com.ibm.portal.puma.User;

//...

public String getCurrentUser(){
  try {
    Context ctx = new InitialContext();
    Name myjndiname = new CompositeName(PumaHome.JNDI_NAME);
    PumaHome myHome = (PumaHome) ctx.lookup(myjndiname); 
    if (myHome!=null) {
      PumaProfile pumaProfile = myHome.getProfile();
      com.ibm.portal.um.User user = (com.ibm.portal.um.User)pumaProfile.getCurrentUser();
      List attributes = new ArrayList();
      attributes.add("uid");
      Map userAttributes = pumaProfile.getAttributes(user,attributes);
      return (String) userAttributes.get("uid");
    }
  }

Answer 2

A Principal represents someone who could potentially authenticate with your application. The Principal's name depends on the authentication method used:

• a username such as "fred" (in the case of HTTP Basic authentication)
• a Distinguished Name such as "CN=bob,O=myorg" (in the case of X.509 client certificates - in which case a X500Principal may be returned)

getRemoteUser() returns "the login of the user" which, in the case of HTTP Basic authentication, will also be the username; it doesn't map cleanly in the X.509 client certificate case though, since the user doesn't enter a "login" as such - in the example above, we could use the Distinguished Name or simply the CN, "bob".

The Javadocs state that "whether the user name is sent with each subsequent request depends on the browser and type of authentication", suggesting that getRemoteUser() was originally meant to provide data only for requests in which a username was entered. This, however, would result in it returning null for the majority of requests when cookie-based auth is in use - not too helpful!

In reality, getRemoteUser() often just calls getUserPrincipal().getName(); verified in Tomcat 6 and Jetty 6/7.

Answer 3

The getUserPrincipal() method returns an object of some class derived from the Principal interface, which is an abstraction of the entity that is the "user" responsible for the request. From it you get an actual object that, depending on the implementing class, you can use to get all sorts of information about that user/identity. One of those properties is the string-representation of the name of the user/identity, which you obtain by calling getName().

getRemoteUser() is really just a shortcut to getting that string-representation. You don't have access to any other methods implemented by the implementing class, not do you have access to the object itself, just the string-representation of the name.

For most use-cases that I am familiar with, that string-representation is what you want; I believe this is why getRemoteUser() exists - it's a common case so there's an easy/quick way to get access to it without actually getting a reference to an implementing class object.