I sent this to the openstack-dev list, and thought I'd double post this onto the openstack list at Launchpad for additional feedback.
-joe Begin forwarded message: > From: heckj <he...@mac.com> > Subject: [openstack-dev] [keystone] Tokens representing authorization to > projects/tenants in the Keystone V3 API > Date: October 19, 2012 1:51:16 PM PDT > To: OpenStack Development Mailing List <openstack-...@lists.openstack.org> > Reply-To: OpenStack Development Mailing List > <openstack-...@lists.openstack.org> > > The topic of what a token can or can't represent for the upcoming V3 Keystone > API came up - and I wanted to share the conversation a bit more broadly to > get feedback. > > > A bit of history: > > In the V2 API, when you authenticated with just a username and password, the > token that was provided wasn't entirely clearly defined. The reference > implementation that Keystone used was to create what's been called an > 'unscoped' token - which was generally limited to only being able to get a > list of possible tenants/projects and the capability of getting a token > specific to a user & tenant/project (what's been called a "scoped" token) > > Likewise, the reference implementation of the rest of the OpenStack projects > all require a tenant information to be included within the token as that > token was the identity refernce inforoamtion - and most OpenStack services > were wanting to know the tenant associated with the token for > authorization/ownership purposes. > > Apparently Rackspace's internal implementation provided a token that was > immediately valid for all possible tenants to which the user was associated, > and presumably their internal implementations of openstack do whatever work > is appropriate to discern and provide that information to the various > openstack services. > > The quandary: > > In the V3 API, we started off with, and currently define the token as being > specifically mandated to a single tenant, with a new requirement that if you > authorize with just a username and password, a "default tenant" is used. If > for some reason you have no tenant associated with the userid, the > authorization is to be refused. If the user is associated with more than one > tenant/project, it's possible to use the token to get a list of other > tenants/projects and request a new token specific to one of those other > tenant/projects, but the implementation is expected to respect and provide a > default. > > A few folks from Rackspace touched on this at the very tail end of the V3 API > review session on Thursday, bringing up that they had an issue with the token > being scoped to a single tenant. Since this has significant implications to > both security and a potential user experience flow, I wanted to bring the > issue up across the broader community for discussion. > > The request outstanding: > > Rackspace folks are requesting that the token not be limited to a single > tenant/project, but instead provides a list of potential tenants against > which the token should be considered valid. > > Brief (maybe shoddy) analysis: > > This would potentially imply changes to what gets passed as a part of the > authentication reference in the context passed using auth_token middleware - > multiple tenants possible instead of the currently expected single value - so > using that as information for create() style mechanisms would need to provide > some alternative means of clearly defining what tenant/project should be > owner. It would provide anyone compromising that particular token with a > broader spectrum of impact on a replay style attack. Likewise, the impact of > tenant enable/disable or role changes would necessarily mean a broader > invalidation of all tokens associated with the user. > > On the flip side, it has the potential to remove the token-reissuance that > currently exists when switching contexts from one project to another > (primarily through horizon or other client/UI/dashboard mechanisms that cache > the token). > > Feedback and Input desired! > > -joe > > > _______________________________________________ > OpenStack-dev mailing list > openstack-...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
