On 02/16/2015 02:21 PM, Samuel Merritt wrote:
On 2/14/15 9:49 PM, Adam Young wrote:
On 02/13/2015 04:19 PM, Morgan Fainberg wrote:
On February 13, 2015 at 11:51:10 AM, Lance Bragstad
(lbrags...@gmail.com <mailto:lbrags...@gmail.com>) wrote:
Hello all,
I'm proposing the Authenticated Encryption (AE) Token specification
[1] as an SPFE. AE tokens increases scalability of Keystone by
removing token persistence. This provider has been discussed prior
to, and at the Paris summit [2]. There is an implementation that is
currently up for review [3], that was built off a POC. Based on the
POC, there has been some performance analysis done with respect to
the token formats available in Keystone (UUID, PKI, PKIZ, AE) [4].
The Keystone team spent some time discussing limitations of the
current POC implementation at the mid-cycle. One case that still
needs to be addressed (and is currently being worked), is federated
tokens. When requesting unscoped federated tokens, the token contains
unbound groups which would need to be carried in the token. This case
can be handled by AE tokens but it would be possible for an unscoped
federated AE token to exceed an acceptable AE token length (i.e. <
255 characters). Long story short, a federation migration could be
used to ensure federated AE tokens never exceed a certain length.
Feel free to leave your comments on the AE Token spec.
Thanks!
Lance
[1] https://review.openstack.org/#/c/130050/
[2] https://etherpad.openstack.org/p/kilo-keystone-authorization
[3] https://review.openstack.org/#/c/145317/
[4] http://dolphm.com/benchmarking-openstack-keystone-token-formats/
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I am for granting this exception as long as it’s clear that the
following is clear/true:
* All current use-cases for tokens (including federation) will be
supported by the new token provider.
* The federation tokens being possibly over 255 characters can be
addressed in the future if they are not addressed here (a “federation
migration” does not clearly state what is meant.
I think the length of the token is not a real issue. We need to keep
them within header lengths. That is 8k. Anything smaller than that
will work.
I'd like to respectfully disagree here. Large tokens can dramatically
increase the overhead for users of Swift with small objects since the
token must be passed along with every request.
For example, I have a small static web site: 68 files, mean file size
5508 bytes, median 636 bytes, total 374517 bytes. (It's an actual
site; these are genuine data.)
If I upload these things to Swift using a UUID token, then I incur
maybe 400 bytes of overhead per file in the HTTP request, which is a
7.3% bloat. On the other hand, if the token + other headers is 8K,
then I'm looking at 149% bloat, so I've more than doubled my transfer
requirements just from tokens. :/
I think that, for users of Swift and any other OpenStack data-plane
APIs, token size is a definite concern. I am very much in favor of
anything that shrinks token sizes while keeping the scalability
benefits of PKI tokens.
Actually, the only tokens that are going to be non-fixed size will be
the ones for Federation, since they need groups. They won't be within
the 255 byte boundary, but they will be small.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
