Syncplicity Support


Application Whitelisting and Scopes

Under admin settings, click on the new setting ‘Application whitelisting and scopes’


Application Whitelisting

Default behavior when application whitelisting is disabled (and no application can be added to the list)

  • When whitelisting is enabled and no Application Keys have been specified, all external applications will be blocked/no application will be able to connect.
  • When whitelisting is enabled and Application Keys have been specified, specified external applications will be un-blocked.
  • When whitelisting is disabled (Default), all external applications will be un-blocked.


Enable application whitelisting, click on save, click 'Add' to add application to the list. Provide application key for the application


Application Key added to the list.


Application Scopes

Why would a customer need Application scopes: To have control on Syncplicity’s APIs that an application can call.

When whitelisting is enabled (which also gives company admin control over scopes), then company admin has at least to whitelist all existing apps and optionally set scopes for them i.e. enabling this feature changes the responsibility of the company admin - now the admin should get to know when someone is creating or wants to use existing 3rd party application to whitlist it (and optionally set scopes).

Following steps need to be undertaken:

  • Customer will have to provision application key/secret ( for the integrating 3rd party application. 
  • In MySite, under Admin setting -> ‘Application whitelisting and scopes’, customer can specify scopes for applications
    • This way customer will have full control of the scopes allowed for this application.


Regarding the 2 radio-buttons:

first option: if the on-behalf-of feature is off for the application, even company admin who logs via this application and by design has the on-behalf-of capability won't be able to use it because it is prohibited for the application (that was used to login this company admin user).

Second option: means that the user logged-in through this application can impersonate other users in the company but only if the user himself is powerful enough (e.g. admin) to use this feature in the first place.

  • Customer will hand over application key/secret pair to the integrating 3rd party application developer.
  • 3rd party application developer will register application key/secret with their application.
  • Syncplicity will enforce the application scopes for this particular application key. 
    • Below Confirmation Dialog would inform (in addition to Syncplicity enforcing app scopes) the end-user about all scopes that app has been entitled to by company admin, so user may also decide if this set of scopes is appropriate or not.




Details on 'API user' and 'Application scopes':

  • We are not replacing API user with application scopes. While scopes work for an application, API user is for a specific user role.
  • While we have adopted the same scopes to make it simple, but the entity that controls the scopes is different.
    • For API User, entity is just a single user which is often used with As-User feature to impersonate others.
    • For Application Scopes, the entity is an application.
  • One major difference between API user and app scopes:
    • For API user, company admin doesn't need to globally turn on whitelisting & scopes feature to allow setting scopes for the app that might replace API User. In API User case it can be implemented without turning whitelisting of all apps globally (= per company by company admin, not globally-globally)
    • For app scopes, company admin needs to turn on company-wide "whitelisting & scopes" feature to start using app scopes functionality. So, from now on company admin has to know about all new legit app keys created by their developers to whitelist them
Powered by Zendesk