Open Stack

Big +1 from me if we can land something solid.

On Fri, Feb 13, 2015 at 3:12 PM, Yee, Guang <guang.yee at 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:blk at 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 <lbragstad at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150213/dde2e375/attachment.html>