The check about project scope and domain scope has a problem

[majianjun]

The keystone.common.authorization.token_to_auth_context function has part check code about scope,
 it as follows:
---
def token_to_auth_context(token):
    ...
    if token.project_scoped:
        auth_context['project_id'] = token.project_id
    elif token.domain_scoped:
        auth_context['domain_id'] = token.domain_id
    else:
        LOG.debug('RBAC: Proceeding without project or domain scope')
   ...
---

However if the token includes the project_scoped and domain_scoped at the same time,it should raise an exception.
But now the above check code does not include the check when the project_scoped and domain_scoped exist at the same time .
Reference the api manual has the following description about scope.
---
The authorization scope includes either a project or domain. If you include both project and domain, this call returns the HTTP Bad Request (400) status code because a token cannot be simultaneously scoped as both a project and domain.
---

[Henry Nash (henry-nash)]

So I agree this is wrong....however, we need to be careful we correcting things like this in case we cause existing applications to fail. We should probably deprecate the "incorrect code" over two cycles, with issuing a warning in the log for now.

[Dolph Mathews (dolph)]

Can you provide an example or an API test to demonstrate that the proposed check ("when the project_scoped and domain_scoped exist at the same time") would even be reachable?

[Steve Martinelli (stevemar)]

unassigning due to inactivity

[Prosunjit Biswas (prosun-csedu)]

The code presented in the bug description favors project scope when both project and domain scopes are available in the token. I found, this is quite a violation of the documentation presented in http://developer.openstack.org/api-ref-identity-v3.html

I wonder, what is the problem if we favor project scope (which is more restricted) over domain scope when both are presented (which the code already does)?

[Brant Knudson (blk-u)]

This should not be marked in progress since there's no review proposed. Still need an answer to comment 2.

[Prosunjit Biswas (prosun-csedu)]

On the findings of comment #2, when requested for a token for

(1). project scope, existing token generation method returns token under valid credential
 Token request curl command and returned token is available here: https://gist.github.com/Prosunjit/f5b859089ec340dd6584

(2). domain scope, existing token generation method returns token under valid credential.
 Token request curl command and returned token is available here: https://gist.github.com/Prosunjit/7bfab9d4c23379da21dc

(3). When both project and domain scope is presented, exiting code returns 400 as specified in the API.
 Token request curl command and return status is available here: https://gist.github.com/Prosunjit/52e0f129e7836a5a0c3c

Code Review:

In file: keystone/keystone/auth/controllers.py
In function: authenticate_for_token

AuthInfo.create() command generates token for incoming token request. When both domain and project scope are present existing code DO check this in the following code and return output following the specification.

   def _validate_and_normalize_scope_data(self):

        """Validate and normalize scope data."""

        if 'scope' not in self.auth:

            return

        if sum(['project' in self.auth['scope'],

                'domain' in self.auth['scope'],

                'unscoped' in self.auth['scope'],

                'OS-TRUST:trust' in self.auth['scope']]) != 1:

            raise exception.ValidationError(

                attribute='project, domain, OS-TRUST:trust or unscoped',

                target='scope')

So, I think, this bug fails to demonstrate its existence.