> Date: Mon, 23 Sep 2013 15:21:16 -0400
> From: ccoleman redhat com
> To: michael mcconachie hotmail com
> CC: dev lists openshift redhat com
> Subject: Re: REMOTE_USER Convo Starter
> ----- Original Message -----
> > Hi team,
> > For a week or two I've been talking to Adam M. (IRC: maxamillion) about a
> > question I have (and for) which I'm trying to get the adoption of OSO in my
> > workplace. Digging around, I see a few excellent and EZ to use plugins for
> > auth mechanisms. After talking to him, it was determined that OSO was also
> > designed to authenticate with almost anything that Apache can serve it (via
> > REMOTE_USER).
> > Of course we all know that most enterprise entities prefer to use KRB or LDAP
> > auth, my client requires any person (who's been issued a DS cert) to be able
> > to "auto-login" in order to use/test this Pilot Environment. My issue is: I
> > can't seem to figure it out how to get it all working using DS Certs.
> > Although, I was able to verify that my specific brand of madness works with
> > the following:
> > 1. A clean install of FC19 on a new VM
> > 2. A configured and working HTTPS Enabled Apache server.
> > 3. Another (different) SS Cert created, and imported into FF Browser.
> > 4. The adjusting SSL params to use: SSLUserName, SSLVerifyClient
> > optional_no_ca (for testing only), and the SSLOptions (standard) Directives.
> > a. A simple CGI script, which dumps all EnvVars.
> > b. REMOTE_USER properly retains the 'SSLVerifyClient SSL_CLIENT_S_DN_CN'
> > contents for EZ usage, and can be tested by calling my test CGI app.
> > The difficulty that I am experiencing trying it against a fresh OSO install,
> > is, that when I tried the same configuration options w/ OSO's proxy -- it
> > doesn't seem to want to authenticate. It falls back to basic_auth. I'll
> > admit that I tried several files, and I can only imagine that there is a
> > specific one that I have to edit. I tried all the standard locations of
> > /etc/httpd, /var/www/openshift/console/httpd/conf.d/, and a few others.
> When you say OSO's proxy, I assume you mean the system httpd (what we call the front proxy)? SSL termination happens at the front proxy today, whereas for most auth solutions up till now mod_auth has been deployed on the individual broker and console httpd instances. In your case, you want to do auth on the front proxy - terminating SSL and setting the REMOTE_USER ENV. When you do that, you'll need to then set the appropriate remote-user header on the proxying request (the one going to either broker or console), so that the console can then retrieve that value. You'll want to completely disable mod_auth on broker and console, since it's handled by the front proxy. You'll need to ensure that incoming requests without SSL verification are rejected properly - I can't guarantee that RHC will cleanly detect a non 401 auth call but in theory it's easy enough for us to fix if there are other required changes. You'll also want to ensure that the broker and console httpd instances are not visible anywhere except the front proxy (or allow SSL only via a client certificate that the front proxy uses).
> The configuration for console and broker should be the standard remoteuser plugins.
Clayton, thank you for the clarification. What I was calling OSO's proxy is actually the front end proxy you've mentioned. (I appreciate your translating what I was trying to ask into something that made sense to the rest of you.) I'll make the necessary changes, and give a report as a follow-up to this thread. Thanks for the assistance, and advice.