Technical Guide – netDocShare architecture

netDocShare SharePoint & Teams app Prerequisites
  • NetDocuments Cloud is required CORS is enabled to close request from unknow sources.
  • Single-Sign On is configured for all AD users so that they are not required to login to Microsoft Teams or NetDocuments Work separately – basically the same login e.g. is used to login to both Teams and NetDocuments.
Solution Architecture
netDocShare Messaging Extension
  • NetDocuments Cloud Server Authentication requests are initiated by netDocShare SharePoint and netDocShare Teams app.
  • Microsoft Teams will request netDocShare app (setup as Teams Personal app or Team Channel Tab) to authenticate
    • netDocShare loads and authenticates against NetDocuments Cloud service
    • netDocShare caches the authentication token and is used to communicate with NetDocuments API.
  • This method applies for upcoming features like netDocShare Messaging Extension.
  • For upcoming feature like netDocShare Bot, the authentication will happen again at KLoBot and KLoBot persists this token and related information for handling voice + text based queries to netDocShare bot.
  • All communication are SSL certified HTTPS requestsets.
  • CORS is enabled to close request from unknown sources.
  • Authentication is not executed by netDocShare, instead it is forwarded to NetDocuments or Single-Sign on Identity Provider.
  • netDocShare Admin App is secured with valid Admins and valid Domains list.
Data: What imDocShare stores
  • netDocShare only stores 2 types of data:
    • Basic Client information such as client name, primary contact, license features, etc.…
    • Configuration information that is required to generate API calls. Examples include:
      • NetDocuments region-based Server Url
      • NetDocuments container ID
      • NetDocuments metadata column names
  • No Document names, content or any other sensitive data is stored.
  • See the next slide for some examples of the above types.
imDocShare - Saved Client Information Example