The concept of a "scope" is applied specifically to tokens. Under the OAuth model, when a token issuer generates a token, it can attach a specific set of scopes to the token. The Apigee product supports this with the OAuthV2 policy, with Operation=GenerateAccessToken. With that policy, you can set the scope on the token, at the time of generation. Later, when the client presents the token for use, you can use the OAuthV2/VerifyAccessToken policy to check the token for a specific scope.
But what you want is something different. Someone is telling you "I don't want OAuthV2 tokens, but I do want scopes." I don't think it works that way. Scopes are a part of the OAuthV2 model. To get actual scopes you need to also accept OAuthv2. You need to use tokens.
But, it may be possible to provide something to your client which satisfies their requirement. When they say "scopes" I suppose they mean, they want an API key which has limited capability. In other words, each API key might have a specific set of capabilities, and at runtime, you'd like Apigee, via the VerifyAPIKey policy, to check those capabilities ("scopes", if you like) during verification.
You might try using custom attributes on the API Key. Each API Key could have a custom attribute with a well-known name. Let's say the attribute is "scope" . And the value of that attribute would potentially be different for each API Key. But in all cases it would be a comma-separated list of words, each identifying a particular scope. "READ,WRITE" might be the value for one API Key, while "READ,WRITE,DELETE" might be the value for another. You can make up these words to suit your model, there is no standard which applies here.
Then , just use the VerifyAPIKey as normal. It is not possible for you to configure the VerifyAPIKey policy to check a specific, named custom attribute for a specific value, as you can with the VerifyAccessToken and Scope element. Instead, you will need to verify access in two steps: first verify that the api key is valid (known, good for the API product, and not expired or revoked). Then, check the scope custom attribute for the desired value. You could do this with a Condition element inside a RaiseFault step. If the condition evaluates true, meaning the required scope is NOT found in the custom attribute, then the RaiseFault send back a 401 unauthorized error.
The key to enabling this: when VerifyAPIKey succeeds, it sets a context variable containing the value of the custom attribute. The name of the context variable will be verifyapikey.POLICYNAME.scope , where POLICYNAME is replaced with the name of the VerifyAPIKey policy itself.
In the flow, what I'm imagining might look like this:
<Flow name="f4">
<Request>
<Step>
<Name>VerifyAPIKey-1</Name>
</Step>
<Step>
<Condition>NOT(verifyapikey.VerifyAPIKey-1.scope ~~ ".*\bREAD\b.*")</Condition>
<Name>RF-Unauthorized</Name>
</Step>
...
</Request>
...
<Condition>...</Condition>
</Flow>
That bit of hieriglyphics in the Condition element is a regex match , followed by a regex that would check for READ scope. The match is negated, so the condition evaluates to true when there is NO match, in other words no READ scope found, and in that case the RF-Unauthorized step executes (presumably a RaiseFault).
LinkedIn
Twitter
