fwiw, the latest patch set has logic built in that determines the purpose of the key repository. If you want your deployment to sign tokens you can point Keystone to a key repository for that purpose. Likewise, tokens will only be encrypted if you tell Keystone to use a key repository for encrypting.
On Sun, Feb 15, 2015 at 12:03 AM, Morgan Fainberg <morgan.fainb...@gmail.com > wrote: > On February 14, 2015 at 9:53:14 PM, Adam Young (ayo...@redhat.com) 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) > 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 think we start with federation usncoped tokens allowing a list of > groups. These tokens only go back and forth from user to Keyston anyway, > and should not got to other services. > > > Scoped tokens via Federation (iirc this is possible) could end up > including the groups. I think you hit the nail on the head though, the 255 > limit is artificial, and we’ve made a lot of efforts here to limit the > token size already. These tokens need to handle 100% of the current token > use cases, and limiting federated tokens to unscoped only is likely going > to break that requirement. Future enhancements can ensure federated tokens > fall below the 255 character limit (IIRC Dolph said he had a fix for this > but it’s not something that can hit Kilo and will be proposed in the > future). > > I also have a concernt with the requirement for new cryptoloy. > Specificcally, the requirement for symmetric crypto and Keys management can > be a s ignificant barrier to organizations that have to meet compliance > rules. Since PKI tokens have already forced this issue, I suggest we > switch AE tokens to using PKI instead of symmetric crypto for the default > case. Putting in an optimization that uses symmetric crypto as an > enhancement should then be a future enhancement. Asymmetric crypto will > mitigate the issues with multiple keystone servers sharing keys, and will > remove the need for a key sharing mechanism. Since this mechanism is in > Keystone already, I think it is a realistic approach. > > > I would rather see this spec crypto all together and strictly rely on HMAC > with any form of crypto (Asymmetric or Symmetric) being the addon. I am > worried if we go down the path of starting with PKI (or even symmetric > crypto) instead of just HMAC signature validation (live-validated such as > what keystone does today with UUID tokens) we are going to back ourselves > into a similar corner we’re in today. > > I agree that adding new crypto and key management is a good deal more > overhead than the basic implementation. As I commented on the spec, I’m not > sure encryption is buying us a lot here. So, lets make the adjustment to > avoid encrypting data and rely on the UUID validation mode utilizing HMAC > signatures (keystone owns the keys) with future enhancements to add in the > actual encryption (in any form). Requiring ASN1 signed data would also not > really the low opportunity cost this spec is trying to be. This eliminates > easy multiple-signer deployments but can be an addon once the core is in > place. > > —Morgan > > > > __________________________________________________________________________ > 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
