[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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
> 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.

> I assume that s ome form of mongo, FakeBasicAuth + htaccess, or other
> authentication mech needs to be explored in conjunction with the REMOTE_USER
> being passed regularly, or with http headers. I also assume that in the case
> of OSO the proxy configs (reverse?) will need some massaging, right? Or is
> it as simple as writing a new plugin? If so, does anyone have a working one
> that I can reference/glean?

You need to use the remote auth plugins.

> A ll of that to ask:
> How does one configure OSO to allow for PKI DS user auth? Even if I can pass
> the correct user info via REMOTE_USER to OSO, I'll still need to add that
> user to the DB with some common/predetermined password --> since the DN is
> the real identifying pice of info that is unique to every user in the org.
> If I get that working, can I still have it fallback to basic_auth incase
> I'll need to login as the admin? (If not, can I assign a 'real' user as an
> admin afterwards?)
> Essentially, if I can avoid it: I don't want to manually enable/create
> accounts for every user; which, in my case will easily span 1k users for my
> test env.
> Thanks ahead of time for my caveman explanations, as I am not a proper dev.
> R/S
> PS: I just left 'The Company' after a few years stint as a GPS Consultant
> (michael redhat com) to work a little closer to home. (We have a new
> addition to the family.) Thank you for all of your hard work, one Red Hatter
> to all you others out there.
> Mike
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]