FW: REMOTE_USER authentication

[Roman CHRENKO]

Hi, Scott.
It looks like misunderstanding.
You (and the documentation too) are talking about "Java world" (IDP, Tomcat) and you use terms from "HTTP world".
And this is the reason, why all your answers are completely wrong.
But I agree with you that naming my variable (used for authentication in Tomcat application) "REMOTE_USER" is not good idea and I will change it.

1. In Java "world" (Tomcat) there are by-default no CGI variables (you can enable CGI interface, which is disabled by default, but IDP doesn't need it and as I know, no one use it). You (in your Java program deployed on Tomcat) can use as inputs only URL, HTTP headers, HTTP body (e.g. parameters in HTTP POST), HttpServletRequest attributes and some methods from httpServletRequest (getRemoteAddr(), ...). You can pull info only from these objects. Forgot about CGI variable - this is Java.
2. The documentation is really wrong. If you look at Tomcat source code, servletRequest.getRemoteUser() returns Principal.getName(). And Principal.name is not filled up with CGI variable REMOTE_USER, because there are no CGI variables in Tomcat. For example if you use basic authentication, look at BasicAuthenticator.java/method authenticate() - username is derived from HTTP header "authorization:" and this String is directly used for constructing Principal. Again, there is no "REMOTE_USER". And now look at the documentation which states: " checkRemoteUser (true or false): whether to look for a principal name in REMOTE_USER". You must agree with me that this part of documentation is completely wrong. The documentation should rather state: checkRemoteUser (true or false): whether to look for a principal name by httpRequest.getRemoteUser(). As I wrote earlier, such statement is precise and not confusing.
3. The 2nd citation from the documentation: If you look at the source code of net.shibboleth.idp.authn.impl.RemoteUserAuthServlet.java, there are in the service() method 3 types how to get username (in this order):
   3a) httpRequest.getRemoteUser() - As I wrote above, this method doesn't use REMOTE_USER,
   3b) for (String s : this.checkAttributes) { Object attr = httpRequest.getAttribute(s); ...} // this.checkAttributes is mapped to checkAttributes init parameter from web.xml
   3c) for (String s : this.checkHeaders) { username = httpRequest.getHeader(s); // this.checkHeaders is mapped to checkHeaders init parameter from web.xml
   And now look at the Shibboleth documentation: "checkHeaders (list of space-delimited request header names): servlet request header(s) to search for a principal name, instead of or in addition to REMOTE_USER."
  There is in the source code RemoteUserAuthServlet.java no "REMOTE_USER" object, nor string.
  So again, also this part of documentation is inconsistent with the implementation - source code. I prefer not to use euphemism - it is wrong (because the source code is correct, it does what is expected).
4. You wrote " REMOTE_USER is not a header". Can you please tell me (in Java world) - what type of object "REMOTE_USER" is?
5. You wrote " That's what it says now.". No, you are wrong. The documentation says not only (as I suggested):
	"checkHeaders (list of space-delimited request header names): servlet request header(s) to search for a principal name."
  But it says: 
	"checkHeaders (list of space-delimited request header names): servlet request header(s) to search for a principal name, instead of or in addition to REMOTE_USER".
 I suggested to remove everything after "instead", because there is no "REMOTE_USER" check in the source code.

Best regards,
Roman




-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Friday, September 2, 2016 3:17 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: REMOTE_USER authentication

On 9/2/16, 5:37 AM, "users on behalf of Roman CHRENKO" <users-bounces at shibboleth.net on behalf of Roman_CHRENKO at tempest.sk> wrote:

> Thanks Scott. Your email was inspiring (although not completely right, 
> because REMOTE_USER generally could be also a httpRequest's header or parameter, not only attribute).

No, it cannot. That is not REMOTE_USER. That's a reserved construct of the CGI interface, and can never be pulled from a header. Naming a header HTTP_REMOTE_USER under the covers doesn't turn the header into REMOTE_USER. It does lead to confusion for people later.

> The documentation at https://wiki.shibboleth.net/confluence/display/IDP30/RemoteUserAuthnConfiguration is wrong. 

No, it's not.

> It says:
>    checkRemoteUser (true or false): whether to look for a principal name in REMOTE_USER
>            This is the first error (I should say "confusion"), because 
> the source code shows that it only check httpRequest.getRemoteUser(), so no REMOTE_USER.

That's what it *means* to check REMOTE_USER.

>            REMOTE_USER can be (in general) httpRequest's attribute, parameter or header.

No, it can't.

>    checkHeaders (list of space-delimited request header names): 
> servlet request header(s) to search for a principal name, instead of or in addition to REMOTE_USER
>           This is the second error, because the souce code shows that 
> it doesn't check "REMOTE_USER" header. You must define it manually in web.xml.

REMOTE_USER is not a header, and the documentation is *telling* you that if you want it to check a header, you have to define that header name in web.xml.

>            The documentation should state: checkHeaders (list of 
> space-delimited request header names): servlet request header(s) to 
> search for a principal name

That's what it says now.

> Then the solution is easy - add the init-param to the servlet:

You're adding a header that *you* named, and leaving a confusing mess for somebody later to come along and misunderstand what it's doing. Do what you like, but I'm telling you after a great deal more experience that using a header named REMOTE_USER is a recipe for confusion. The header name you set doesn't matter, and you shouldn't set headers that conflict with existing CGI interface names.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net