Big +1 from me if we can land something solid. On Fri, Feb 13, 2015 at 3:12 PM, Yee, Guang <guang....@hp.com> wrote:
> ++ > > > > As for the unbound groups concern, our initial internal Federation POCs > worked well with a single group so far. The proposed hierarchical role > groups, or perhaps even supporting nested user groups down the road should > offer us more flexibility in terms user and permission management. For > example, having a single aggregated group to map to for the federated users. > > > > Personally, I think the max 255 characters constraint is somewhat > artificial, unless I am missing something here. > It's a limitation made for social reasons: that's sort of the tipping point where tokens become unwieldy and require special treatment. > > > > > Guang > > > > > > *From:* Brant Knudson [mailto:b...@acm.org] > *Sent:* Friday, February 13, 2015 12:59 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption > (AE) Tokens > > > > > > We get a lot of complaints about problems caused by persistent tokens, so > this would be great to see in K. Given the amount of work required to get > it done, which includes taking care of some other issues, like getting > revocation events working and refactoring the token code (things which > could have been progressing all along...), and considering how long it > takes to get changes merged, it seems unlikely that this will make it, but > I've been planning all along to prioritize these reviews if that helps. > > - Brant > > > > On Fri, Feb 13, 2015 at 1:47 PM, 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 > > > > __________________________________________________________________________ > 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