cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
240
Views
0
Helpful
3
Replies

Access Denied on update APIs from Webex CC Desktop widget

kseraphine
Contributor
Contributor

I'm trying to create a Webex CC Desktop widget that will allow users with supervisor rights to modify skill profile proficiency values.

Using a token issued through my own integration (or a developer token from developer.webex-cx.com) a supervisor is able to use the  /organization/{orgId}/skill-profile/{id} endpoint to update a skill profile. 

However, using the token from STORE.auth.accessToken the same supervisor account receives a "403: Access denied - Client is forbidden access to the resource" when trying the update a skill profile.

Is this the expected result?

Please let me know if any additional information would be helpful.

Thank you

3 Replies 3

Arunabh Bhattacharjee
Cisco Employee
Cisco Employee
Hi,

This is expected, because, when logging into the desktop, the Desktop code does not request for cjp:config_write scopes.
This is because we are unable to understand which users need / have the scopes to write configuration.
Hence the STORE’s token only has the config_read scope.

The right way to do this would be to build a service that offers the token to the widget.
This is because the scope requested has to have cjp:config_write, the token then has access to that scope, and then that token is used to execute skill profile updates.

i.e skill-widget@org.com user – Admin user – used as a system account for the widget.
Widget then uses this token for the skill updates.

Supposed you still followed the STORE accessToken method, then a user with a specific supervisor profile that only had View access to the Provisioning module would get an error while logging into the desktop

Error: missing scope cjp:config_write

So it is safer to frontend the widget with an Admin token, or a specific supervisor token (supervisor-widget@org.com)

Thanks & Regards,
Arunabh.

Thanks for the quick reply.  Your explanation of why the desktop token is scoped for read only makes sense.

If I understand your external service suggestion correctly, it would do the following:
* provide an interface to allow and admin to do an Oauth flow
* offer an endpoint to provide the token upon request from the desktop widget

An external service such as this is a major impediment to migrating many of our traditional on-premises CCX customers

In order to meet customer security requirements such a service would require:
- SSO login for the admin/Oauth route
- Some authorization mechanism for the widget route

If the widget's functionality is considered mission-critical , it would also require redundancy.

This adds a significant support burden and cost and works against the main impetus for cloud migrations.

If I am interpreting your suggestion incorrectly, please let me know.

Perhaps you could consider an enhancement to `Desktop.actions.getToken() ` to provide an option to request a writable token?

Thanks