Access Denied on update APIs from Webex CC Desktop widget
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-22-2022 04:20 PM
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
- Labels:
-
Webex Contact Center APIs
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-23-2022 07:43 AM
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
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-25-2022 08:07 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-11-2022 01:18 PM
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.
