Access Denied on update APIs from Webex CC Desktop widget

[kseraphine]

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

[Arunabh Bhattacharjee]

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.

[kseraphine]

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

[Arunabh Bhattacharjee]

Hi,

Regarding : provide an interface to allow and admin to do an Oauth flow

- Yes, you can perform the OAuth2 on postman and hardcode the access_token, refresh_token inside your app, once, during setup/onboarding. you can definitely build a front end for this but you can set it up once for a backend token refresh.

Regarding: offer an endpoint to provide the token upon request from the desktop widget

Yes, in this example (video in the readme) - the token is provided in an endpoint 

/token 

and requires some additional key/value pairs to ensure token is returned to an authorized party.

https://github.com/CiscoDevNet/webex-contact-center-api-samples/tree/main/token-app-sample 

This is basically a middleware that returns a valid access Token to be used continously for Admin related operations for other applications.

Regarding: increased support burden and cost and works against the main impetus for cloud migrations.

Yes, that is true in the case of requiring middleware for this. There is no API key / one time access token as of today.

The Widget has to be hosted as a compiled bundle on a CDN, there is no way to host widgets locally on the desktop today.

The problem with Desktop.actions.getToken() as of today is that the token requested has to be requested initially upon login by the desktop application - and agents do not have the writable scope by default. Ony supervisors and admins have this scope. Hence in any case the agents using the widget will not be able to request for a writable token by default.

I have asked internally if we can add this functionality, at this point it is not being prioritized. 

Thanks & Regards,

Arunabh.