Bug 1128987 - [x509]rhc always ask for generating a token when switching to a "x509 enabled" server
Summary: [x509]rhc always ask for generating a token when switching to a "x509 enabled...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 2.1.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
: ---
Assignee: Brenton Leanhardt
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-12 03:19 UTC by Gaoyun Pei
Modified: 2014-08-26 13:53 UTC (History)
4 users (show)

Fixed In Version: rhc-1.29.3.1-1.el6op
Doc Type: Bug Fix
Doc Text:
Cause: Previously only the username+server was used as the key for looking up client tokens on disk. With x509 authentication rhc does not know the username. Consequence: Token retrieval was not working correctly. Fix: Each authentication method for RHC now defines a key that is used for token retrieval. For Basic auth it's the username. For x509 it's the fingerprint of the certificate. Result: Updating RHC is all that is need to pick up this fix. Since this is the first OpenShift Enterprise release shipping an x509 rhc package no users were actually affected by this bug.
Clone Of:
Environment:
Last Closed: 2014-08-26 13:53:13 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1095 normal SHIPPED_LIVE Red Hat OpenShift Enterprise 2.1.5 bug fix and enhancement update 2014-08-26 17:51:34 UTC

Description Gaoyun Pei 2014-08-12 03:19:13 UTC
Description of problem:
After adding a server which is using mutual SSL authentication and x509 certificates, when switch back to this server using 'rhc server use <hostname>', rhc client always prompt user to generate a token.

Version-Release number of selected component (if applicable):
rhc-1.28.5.1-1.el6op.noarch

How reproducible:
always

Steps to Reproduce:
1.Add the server using 'rhc server add '
[root@dhcp-129-188 ~]# rhc server add broker.ose21z-0808.x509.com ose1 --ssl-ca-file File --ssl-client-cert-file File --ssl-client-key-file File

OpenShift can create and store a token on disk which allows to you to access the server without using your password. The key is stored in your
home directory and should be kept secret.  You can delete the key at any time by running 'rhc logout'.
Generate a token now? (yes|no) yes
Generating an authorization token for this client ... lasts about 6 hours

Saving server configuration to /root/.openshift/servers.yml ... done


2.Check the generated token
[root@dhcp-129-188 ~]# ls ~/.openshift/token_*
/root/.openshift/token_ZeeQxFyYeexGoLjbqgHKQ
[root@dhcp-129-188 ~]# cat /root/.openshift/token_ZeeQxFyYeexGoLjbqgHKQ
e8d565c16827100d32e9e832e8c6a60de5b7079e29b801259071a741b1208fb8


3.Switch to this server
[root@dhcp-129-188 ~]# rhc server use ose1
Using gpei to login to broker.ose21z-0808.x509.com

OpenShift can create and store a token on disk which allows to you to access the server without using your password. The key is stored in your
home directory and should be kept secret.  You can delete the key at any time by running 'rhc logout'.
Generate a token now? (yes|no) yes
Generating an authorization token for this client ... lasts about 5 hours

Saving configuration to /root/.openshift/express.conf ... done
Saving server configuration to /root/.openshift/servers.yml ... done

Now using 'broker.ose21z-0808.x509.com'


4. Check existing token again. Still the same token.
[root@dhcp-129-188 ~]# ls ~/.openshift/token_*
/root/.openshift/token_ZeeQxFyYeexGoLjbqgHKQ
[root@dhcp-129-188 ~]# cat /root/.openshift/token_ZeeQxFyYeexGoLjbqgHKQ
e8d565c16827100d32e9e832e8c6a60de5b7079e29b801259071a741b1208fb8


Actual results:

Expected results:
Should using the existing token.

Additional info:
This wouldn't happen on a normal ose broker.
[root@dhcp-129-188 ~]# rhc server use ose2
Using an existing token for gpei to login to xxx.xxx.xx.xx

Saving configuration to /root/.openshift/express.conf ... done
Saving server configuration to /root/.openshift/servers.yml ... done

Now using 'xxx.xxx.xx.xx'

Comment 4 Gaoyun Pei 2014-08-14 02:24:30 UTC
Verify this bug with rhc-1.29.3.1-1.el6op.noarch.

Add two latest ose-2.1.z servers to server list, one of them is using x509 authentication.

[root@dhcp-129-188 workspace]# rhc server list
Server 'ose1' 
----------------------
  Hostname:                  broker.ose21z-0808.x509.com
  Login:                     gpei
  Use Auth Tokens:           true
  Insecure:                  false
  SSL x509 Client Cert File: xxx
  SSL Cert CA File:          xxx

Server 'server1' (in use)
----------------
  Hostname:        xxx.xxx.xx.xx
  Login:           gpei
  Use Auth Tokens: false
  Insecure:        true

Switch back to "ose1" env:
[root@dhcp-129-188 workspace]# rhc server use ose1
Using an existing token for gpei to login to broker.ose21z-0808.x509.com

Saving configuration to /root/.openshift/express.conf ... done
Saving server configuration to /root/.openshift/servers.yml ... done

Now using 'broker.ose21z-0808.x509.com'

Move it to VERIFIED

Comment 5 openshift-github-bot 2014-08-15 16:26:14 UTC
Commits pushed to master at https://github.com/openshift/rhc

https://github.com/openshift/rhc/commit/8af46e9858f58d8533211fc17df0785e7800e3bc
Bug 1128987 - prevent rhc from needlessly regenerating tokens with x509 auth

https://github.com/openshift/rhc/commit/7df253c1696a8a4ca3dc620263abbcf1aa1f7e4e
Merge pull request #1 from brenton/rework_token_fallback

Bug 1128987 - prevent rhc from needlessly regenerating tokens with x509 ...

Comment 7 errata-xmlrpc 2014-08-26 13:53: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.

http://rhn.redhat.com/errata/RHBA-2014-1095.html


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