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

RE: REMOTE_USER Convo Starter



Brenton --

Thanks for the encouragement, and willingness to assist me in this effort; I sent a reply PM to your corp addy.

I'm currently building out a new env, and will test your recommendations tonight (and get back to you tomorrow).

I appreciate yours', and everyone else's help.

Thanks All!

MM



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