During the validate token call all the tenant roles (associated with the tenant scoped token) are returned to the middle-ware component and then passed along in the X_ROLES header to the OS service for consumption. In the case were more than one OS service are bound to the same tenant (e.g. Swift and Nova, or Nova 1 and Nova 2), a user with particular role for one service, lets just say the 'Admin' role will now also have the 'Admin' role in the second service. This is because roles are currently only scoped to the tenant level. The middle-ware just takes all returned tenant roles and stuffs them into the X_ROLES header regardless of the actual service the middle-ware is protecting. A quick fix to this problem would be to change the validate token interfaces (GET/HEAD /tokens/{tokenId}) to require a {serviceId} filter... so something like GET /tokens/{tokenId}?serviceId={serviceId}. The Keystone service would then only return roles in the response that are tied to that specific serviceId. If the serviceId was not provided, or was invalid, or no roles where found for that serviceId, then a 401 would be returned. Future Keystone work could consider allowing to filter down to the {endpointId}, but for such a change it would require a data model change to allow serviceIds to be defined on endpoint references.... Not to mention more API changes.
Subscribed Ziad, as PTL for Keystone.
If I understand correctly, this is more an unfortunate design choice (roles being scoped to tenants) than a security flaw ? If you confirm that the current behavior is by design, I agree that this design should be improved to allow roles scoped to tenant + service, but I see no reason to keep this private.
If this is not by design and roles should actually be scoped to tenant + service, then this is a vulnerability and we should keep the bug private until this is fixed. And if this affect stable/diablo as well, I suggest we delay 2011.3.1 to include the fix...