Bug 1187806 - Allow the `no_auth` request variable to be configured
Summary: Allow the `no_auth` request variable to be configured
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 2.2.0
Hardware: x86_64
OS: Linux
high
medium
Target Milestone: ---
: ---
Assignee: John W. Lamb
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks: 1216206
TreeView+ depends on / blocked
 
Reported: 2015-01-30 21:37 UTC by Timothy Williams
Modified: 2019-05-20 11:28 UTC (History)
13 users (show)

Fixed In Version: rhc-1.35.2.1-1.el6op
Doc Type: Bug Fix
Doc Text:
When using a client certificate configuration on brokers, such as mutual SSL or x509 authentication, REST API requests to the broker from the client tools would fail. This was due to the requests not including authentication credentials, as the client tool had the "no_auth" request variable hard-coded to "true". This bug fix updates the client tools to add the "always_auth" option to the client tools configuration file (the ~/.openshift/express.conf or ~/.openshift/servers.yml file). This option defaults to "false", yielding the original behavior; when set to "true", the client tools use an authenticated connection for all requests. As a result, this allows the client tools to now fully communicate with the broker as expected when using a client certificate configuration on brokers.
Clone Of:
: 1216206 (view as bug list)
Environment:
Last Closed: 2015-04-06 17:06:13 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0779 0 normal SHIPPED_LIVE Red Hat OpenShift Enterprise 2.2.5 bug fix and enhancement update 2015-04-06 21:05:45 UTC

Description Timothy Williams 2015-01-30 21:37:02 UTC
Description of problem:
Currently, the `no_auth` request variable is hard-coded to 'true'. This variable determines whether to send an 'auth' option in a new request. When modifications are made to the OpenShift broker to only allow https communication, it is necessary to set 'no_auth' to false so that auth is sent with every request.

Version-Release number of selected component (if applicable):
OSE 2.2

Comment 3 Luke Meyer 2015-02-02 14:18:15 UTC
I'd call this a bug. It makes x509 auth unworkable. Also it's fairly low-hanging fruit.

I think it might be possible to work around this by setting use_authorization_tokens false in express.conf / servers.yaml? That way it should expect to need the client cert all the time for auth. But I don't have a system handy to test, may just be guessing.

Comment 4 Ken Evensen 2015-02-03 12:14:27 UTC
Luke,

I've tried setting the use_authorization_tokens to false in the servers.yaml.  Unfortunately it didn't alleviate the issue.  The only way I could make this work is by altering the code in the ruby gem.

If you have another thought, I'd be happy to try it.

Ken

Comment 6 Luke Meyer 2015-02-17 16:48:45 UTC
Normally authentication is excluded for the /broker/rest/api endpoint, because the client needs to reach that in order to determine how to authenticate, so it would be a loop (try to authenticate, how? check /api - oh, we need to authenticate...).

With x509 client cert auth in place, that's obviously not necessary, but the code remains.

It would be easiest by far if the server could exclude just the /broker/rest/api endpoint from requiring the client cert. There would be no need for special client config.

The other alternative would be introducing an option "always_auth" that can be added to rhc config for this situation, in which case every user would need to know to do that (or possibly rhc setup could be modified to introduce it automatically when x509 auth is indicated).

Comment 8 openshift-github-bot 2015-03-13 16:44:14 UTC
Commit pushed to master at https://github.com/openshift/rhc

https://github.com/openshift/rhc/commit/d0f0e6af448c77565a83eeb1ccb942be709bb6c2
Add "always_auth" config option

On systems where x509 client cert authentication is needed for every
REST API URL, the API requests from `RHC::Rest::Api#initialize` will
fail since they don't include the authentication credentials. This
change adds the "`always_auth`" config option which, when set to
"`true`" forces auth for all REST API calls. The setting defaults to
"`false`", yielding the original behavior.

Enterprise bug 1187806
https://bugzilla.redhat.com/show_bug.cgi?id=1187806

Comment 11 Gaoyun Pei 2015-03-20 08:48:41 UTC
Verify this bug with package rhc-1.35.1.1-1.el6op.noarch.
In /usr/lib/ruby/gems/1.8/gems/rhc-1.35.1.1/lib/rhc/rest/api.rb,
RHC::Config['always_auth'] is getting a string not a bool, no matter "true" or "false" setting for option "always_auth" in ~/.openshift/express.conf, "no_auth" would always get to be"false".

Comment 12 John W. Lamb 2015-03-23 21:53:48 UTC
This should be addressed by the changes in https://github.com/openshift/rhc/pull/677 - I will try to get this into a puddle first thing tomorrow.

Comment 14 Gaoyun Pei 2015-03-26 08:43:29 UTC
Verify this bug with rhc-1.35.2.1-1.el6op.noarch.

Set up an ose env with x509 auth enabled on broker, make sure /broker/rest/api requires auth.

Configure cert files in ~/.openshift/express.conf and enable always_auth=true.
[root@broker ~]# cat ~/.openshift/express.conf
ssl_client_key_file=/root/ose.key
ssl_ca_file=/root/ca.crt
ssl_client_cert_file=/root/ose.crt

libra_server=broker.ose22-manual.com.cn

always_auth=true

[root@broker ~]# rhc domain create mydomain
Creating domain 'mydomain' ... done
You may now create an application using the 'rhc create-app' command
[root@broker ~]# 
[root@broker ~]# rhc domain show
Domain mydomain (owned by user)
-------------------------------
  Created:            1:39 AM
  ID:                 5513c5dce5fed54a68000003
  Allowed Gear Sizes: small, medium
  Suffix:             ose22-manual.com.cn

The domain mydomain exists but has no applications. You can use 'rhc create-app' to create a new application.

Change always_auth=false
[root@broker ~]# rhc domain show
You are not authorized to perform this operation.

Comment 17 errata-xmlrpc 2015-04-06 17:06:13 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0779.html


Note You need to log in before you can comment on or make changes to this bug.