Syncplicity Support

Follow

Application Whitelisting and Scopes

By default, whitelisting and scopes are disabled. This allows all external applications to be un-blocked. When whitelisting and scopes are enabled, your organization's admin has the option to block all or specific applications. When whitelisting is enabled:

  • Application Keys specified: All external applications are blocked/no application can connect.
  • Application Keys not specified: Selected external applications are un-blocked.

Applications scopes allow company admins to have control over Syncplicity's APIs that an application can call.  When whitelisting is enabled (which also provides control over scopes), and the admin has whitelisted all of the existing apps, the admin can (optionally) set scopes.

Use Case

Your company admin has the responsibility of knowing when someone is creating or wants to use existing 3rd party application. To avoid security issues and to help your organization protect their data, the admin has enabled the Whitelisting and Scopes feature to block selected external applications to prevent specific applications from connecting.  The admin has also specified scopes for application. This allowed the admin to fine-tune the permissions associated with the whitelisting. 

Enable Whitelisting 

Admin → Settings → Application Whitelisting and Scopes → Enabled 

To enable application whitelisting:

  1. Go to Admin → Settings. 
  2. Click Application Whitelisting and Scopes


  3. Click Enabled (by default, Application Whitelisting is disabled).

Add an Application Key to the whitelisting list

Admin → Settings → Application Whitelisting and Scopes → Enabled → Add

To add a new application key to the whitelisting list:

  1. Click Add to add the application to the list.
  2. Enter a name and an application key. 
  3. Click Save.

Edit Application Scope

This page allows you to select controls on Syncplicity’s API that this application can call.

To edit the application scope:

  1. Provision an application key/secret (https://developer.syncplicity.com) for the integrating 3rd party application.
  2. Go to MySite, under Admin setting→ Application whitelisting and scopes, and specify the scopes for applications. This provides full control of the scopes allowed for this application.

  • Select Access only own content through API: If the on-behalf-of feature is off for the application, even a company admin that logs in thru this application (and by design has the on-behalf-of capability), will not be able to use it because it is prohibited for the application (that was used to login this company admin user).
  • Select Access content on behalf of managed users through API:  Allows the user that is logged-in through this application to impersonate other users in the company ONLY if the user is powerful enough (such as an admin) to have access to this feature.
    • You must provide application key/secret pair to the integrating 3rd party application developer.
    • The 3rd party application developer must register the application key/secret with their application.
    • Syncplicity will enforce the application scopes for this particular application key.

The following screen informs the end-user (in addition to Syncplicity enforcing app scopes) of all scopes that app has been entitled to by company admin. This allows the user to decide if this set of scopes is appropriate or not.

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

  • API user with application scopes is not replaced. 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, the entity that controls the scopes is different.
    • For API User, entity is only a single user which is often used with the 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, the company admin does not need to globally enable the Whitelisting & Scopes feature to allow setting scopes for the app that might replace API User. In API User case, it can be implemented without enabling whitelisting of all apps globally (= per company by company admin, not globally-globally).
    • For app scopes, the company admin must enable the company-wide Whitelisting & Scopes feature to start using the app scopes functionality. After this point, the company admin must know about all new legit app keys created by their developers in order to whitelist them.
Powered by Zendesk