Bug 1300855

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