Layer7 API Management

How can i overwrite OTK SCOPE issuing assertion which is encapsulated? i need that 'oob' should not be returned when no scope is specified in request, but the cases defined within this assertion does not allowed me to do that. also ,i need to handle multiple scopes, any inputs are appriciated 

Hi jaykumar.solanki,

let me see if i understand your questions.

1. In the first question, you would like to find out how to request for token that does not return "scope" value when it is not in your request parameter. Is there any specific grant_type you need to use for this request?

2. In the second question, you would like to request token that can handle multiple scopes. For this particular question, have you try creating OAUTH client key in OAuth Manager with multiple scopes?

What OTK version are you using in your deployment?

Hey, 

1) My first question is ,even if i'm not passing any valid scope in request i'm getting a token with scope 'oob', later on i found that OTK SCOPE issuing encapsulated assertion is having a scenario where it is mentioned if no scope is specified than return token with 'oob' scope, which i want to override but i'm not able to.

2)Yes, i do have a client registered with 2 scopes as READ WRITE, but If i try to generate the token specifying these 2 scopes, i'm again getting token with scope 'oob' , which is again implemented within OTK SCOPE issuing encapsulated assertion and i'm not able to change it as it is read only.

In short i need a way to change/override above encapsulated assertion, as per my understanding but i'm not sure how

I see.

Currently OTK SCOPE issuing encapsulated assertions is not customize-able. But there is another way.

You can write your own custom grant_type in OTK grant_type=custom. Below is the link on how to do it: Support Custom Grant Types - CA API Management OAuth Toolkit - 4.2 - CA Technologies Documentation 

To control the return you desired, you can construct the "clientResponse" to having a desired scope such as : ${scope.registered} being returned, or you can simply specify which scope you want to be returned. Alternatively, you can remove the "scope" from the JSON response.

Just be aware that the reason we return "oob" when no scope is requested is for security reason - to avoid client spoofing.

Hey,

Yes I'm already using OTK grant_type=custom, what i need is to make changes in the scope validation scenarios which are present in OTK SCOPE issuing, is there anyway? As the way you've mentioned does not fulfill my requirement, i don't simply want to return 'scope.registered' or 'scope.granted' when no scope is requested.

Do you mind to take this conversation to email as i may need to ask you some details about how your requests looks like and how your policy for OTK grant_type = custom looks like to better assist you.

My email address is helen.kestury@ca.com

Good afternoon,

For "question 1" how to customize Scope issuing:

The OTK Scope issuing assertion is read-only. The existing logic to determine what scope to grant is below (note that scope string is case sensitive):

1. If no scope is registered or only oob is registered, granted scope will always be oob
2. If no scope is requested, granted scope will always be oob
3. If scope requested matches exactly scope registered, the requested scope will be granted
4. If scope(s) requested is/are subset of scope registered, the requested scope(s) will be granted
5. If scope(s) registered is/are subset of scope requested, in other word, if some of the scope(s) requested is/are not in the scope registered. Only the requested scope(s) that are within the registered scope will be granted, the rest will be removed.
6. If none of the scope(s) requested are in the scope registered, returns failure

The scope issuing logic is designed in consideration that Authorization server won't expose what has been registered for the client to prevent spoofing, we highly recommend you stay with the OOTB behavior. however some level of customization can be added to manipulate the input or output of the assertion in the service endpoint the to alter the result.

For Authorization_code flow, scope issuing is invoked in Authorization endpoint. 

For the other grant types, it is invoked in Token endpoint

Note:  Changes made to service endpoint will be overwritten after upgrade, manual merge required to reapply the change.

Here are some examples: 

E.g. Use custom grant type to manipulate the scope.granted at token endpoint.  the Custom grant type can define a new grant type or can replace an existing grant type depending on your needs.

For example, you want to change the scope behavior for the password grant type:

• Implement a custom grant_type to replace an the password grant
• In screenshot below,  for scenario 1) and 2), instead of oob, the registered scope will be granted. 

E.g. If you want change the scope behavior for all grant types at one place,  manipulate the scope.requested before calling OTK Scope Issuing may give you the desired result. 

• In the screenshot below, add logic before calling OTK Scope issuing assertion, check if ${request.http.parameter.scope} is empty,  if so set it to scope.registered. This will make scenario 2 always grant registered scope when no scope is requested 

For Question 2: OTK does support multiple scope values, If the response granted scope is "oob", it could be because the condition falls to the scenario 1 or 2. remember the string is case sensitive.

Sincerely,

Stephen Hughes

Broadcom Support