++

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.


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<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://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

Reply via email to