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

Re: REMOTE_USER Convo Starter



+++ The Dude [23/09/13 04:51 +0000]:



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.I assume that some 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?
All 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

Hi Mike,

It sounds like you've done your homework on this.  I can answer a few
of your questions now, and then I suspect you will have others.  If we
struggle to get this working we may be able to find a time we can meet
online and debug this together.  I'm fairly confident we can get this
working without needing to modify OpenShift code.

I'm working off an OpenShift Enterprise installation but the
principles are the same.  On my system these are the files that would
need to be modified:

/etc/httpd/conf.d/000002_openshift_origin_broker_proxy.conf
/var/www/openshift/broker/httpd/conf.d/openshift-origin-auth-remote-user.conf
/var/www/openshift/console/httpd/conf.d/openshift-origin-auth-remote-user.conf

On a normal Broker+Console machine there is a toplevel Apache
listening on 443 that handles SSL termination.  It then proxypasses to
the Broker's Apache or the Console's Apache depending on the request.

Let's first discuss the simple htpasswd backed setup.  I believe
Origin ships the sample configuration files for reference.  In that
case both the Broker and the Console would need to access to the
htpasswd file.  These Apaches are running on the loopback interface.

If a request reaches the Broker from the toplevel apache it will
trigger the authentication logic found in in the Broker's
openshift-origin-auth-remote-user.conf.  However, if the request comes
directly from the console over the loopback interfact then the Broker
will trust the value of the X-Remote-User header since the Console has
already verified the password.

Therefore, one way to go about this would be change the trust
relationship to be between the Apache that terminates SSL and the
Broker/Console.  If you can guarantee the following then I think it
will work:

(Top level Apache == SSL termination Apache)

* Top level Apache validates the client certificate and then sets
  X-Remote-User on the request to either the backend Broker or Console
* For any request that doesn't have a valid SSL certificate it then
  removes the REMOTE_USER/X-Remote-User header from the request (to
  avoid someone trying to be evil)
* For the backend Apaches you would need the following configuration:

  SetEnvIf X-Remote-User "(..*)" REMOTE_USER=$1

We'll likely have to tweak it a bit to cover all edge cases but this
is the general idea.  I'm sure this will lead to more questions so
don't hesitate to ask.  I'll setup an Origin environment in the
meantime and play around with this as time allows.

--Brenton

		 	   		

_______________________________________________
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]