Keystone supports a number of different token formats[1]. Currently RGW only supports UUID. RGW should also support PKI, PKIZ and Fernet. [1] http://docs.openstack.org/developer/keystone/configuration.html#token-provider
nb, we do support PKI tokens.
Thanks for clarifying.
Note that there is already a similar report at: http://tracker.ceph.com/issues/12761 However, the description in that report states that PKIZ tokens do work. I can't see how/where this is handled in the code so looking for a confirmation from engineering please?
Your interpretation of the code matches ours: we don't think PKIZ token format is actually supported. We'll post an update when we have verified more fully.
Actually, it does work. We setup a test cluster and verified this ourselves when this bug and associated ticket stalled. Here's some output using our production Radosgw gateway now that it is using Keystone with PKIZ: --- blair@bethwaite:~$ env | grep OS_ OS_TENANT_ID=d57d08aef288840e199bb1a49ae232c78 OS_PASSWORD= OS_AUTH_URL=https://keystone.rc.nectar.org.au:5000/v2.0/ OS_USERNAME=Blair.Bethwaite OS_TENANT_NAME=R@CMon_Porting blair@bethwaite:~$ swift --version python-swiftclient 2.7.0 blair@bethwaite:~$ swift --debug --os-storage-url https://au-east.erc.monash.edu.au/swift/v1 stat DEBUG:keystoneclient.auth.identity.v2:Making authentication request to https://keystone.rc.nectar.org.au:5000/v2.0/tokens INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): keystone.rc.nectar.org.au DEBUG:requests.packages.urllib3.connectionpool:"POST /v2.0/tokens HTTP/1.1" 200 8874 INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): au-east.erc.monash.edu.au DEBUG:requests.packages.urllib3.connectionpool:"HEAD /swift/v1 HTTP/1.1" 204 0 DEBUG:swiftclient:REQ: curl -i https://au-east.erc.monash.edu.au/swift/v1 -I -H "X-Auth-Token: PKIZ_eJytWVt3oswSfe9fcd6zv ...more token... N1dzcq6M8t_aNp-ZKf_nHCMIsmj7NqWamGV3Mk363z0d3jnTgTn2NZN4Qlmhkdvv-tP_1Zz0tX-6-C-lexuq29vpb9F8K7-7g=" DEBUG:swiftclient:RESP STATUS: 204 No Content DEBUG:swiftclient:RESP HEADERS: [('Content-Length', '0'), ('X-Account-Object-Count', '12'), ('X-Account-Bytes-Used-Actual', '14971854848'), ('X-Trans-Id', 'tx00000000000000001e22d-0057029383-c9bd6-au-east'), ('Date', 'Mon, 04 Apr 2016 16:17:09 GMT'), ('X-Account-Bytes-Used', '14971838040'), ('X-Account-Container-Count', '7'), ('Content-type', 'text/plain; charset=utf-8'), ('Accept-Ranges', 'bytes')] Account: v1 Containers: 7 Objects: 12 Bytes: 14971838040 X-Account-Bytes-Used-Actual: 14971854848 X-Trans-Id: tx00000000000000001e22d-0057029383-c9bd6-au-east Content-Type: text/plain; charset=utf-8 Accept-Ranges: bytes --- Note in the output above that the token has the prefix "PKIZ_" and that the "swift stat" (basically, getting account info) completed successfully. Hopefully this info can help avoid anyone unwittingly breaking this feature!
Support is complete in Jewel (though PKIZ tokens are deprecated in OpenStack).
(Correcting myself: we support all Keystone token types, including the preferred Fernet tokens, in Jewel.)
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/RHSA-2016-2815.html