Explicitly Unscoped Tokens¶
The V3 API provides no way to request an unscoped token if the user has a
default_project_id set.
Problem Description¶
Keystone has the concept of a default_project_id which means that if a
scope is not specified on an authentication request the scope is assumed to be
the default_project_id. This makes it impossible for a user with a
default_project_id set to gain an unscoped token.
Proposed Change¶
Add a mechanism to specify that an unscoped token is requested regardless of
the presence of a default_project_id.
Alternatives¶
None.
Security Impact¶
Ideally for security purposes we would like to maintain our explicit separation
of scoped and unscoped tokens. This could be the first step in removing the
default_project_id and enforcing the unscoped workflow.
Notifications Impact¶
None.
Other End User Impact¶
Keystoneclient will need to have a new option on its authentication plugins to signal that an unscoped token is required. This should not change the typical flow of an application as it would already need to handle the case where the token it received was unscoped.
Performance Impact¶
None.
Other Deployer Impact¶
None.
Developer Impact¶
This will lead to greater consistency in authentication flows.
Implementation¶
Assignee(s)¶
- Primary assignee:
jamielennox
- Other contributors:
ayoung
Work Items¶
Add the change to authentication routes.
Add the option to auth plugins in keystoneclient.
Dependencies¶
None.
Documentation Impact¶
There is a new option available in the identity-api and a corresponding new option on the auth plugins in keystoneclient.
References¶
None.
