Overview

At Moveworks, the Permissions Platform for searchable content can be configured in 3 ways:

• Mirrored Permissions: Rules from the source content system are respected and mirrored directly by Moveworks during ingestion, referring to Users / Groups / Roles and the rules associated with them.
• Managed Permissions: Rules written into the Moveworks Setup configuration that enforce access restrictions via ACL.
• User Consent Permissions: Used in Live Search retrieval, the connection is granted via oAuth to the source content system on a user-by-user basis, and calls to the system at query time use the oAuth token which enforces permissions natively.

Mirrored Permissions

For an overview of our overall Mirroring architecture, you can refer to Content Ingestion Platform.

The overall flow is similar to how Moveworks mirror content: Customer Dataset Records are generated during the mirroring to be loaded. Moveworks mirrors permissions from external systems to the permissions store [OpenFGA or Redis for ServiceNOW permissions] and also propagate it to the content index [Instadex]. Once permissions are stored, Moveworks is able to leverage pre-filtering (during retrieval) and post filtering (after retrieval) of content to ensure that the AI Assistant and Enterprise Search only serve content that a user should be allowed to view.

The content permissions is applied in two ways:

• Pre-Filtering: During loading of content into the customer’s index, the Permissions Loader will write the Relationship Based Access Control (ReBAC) rules into OpenFGA, and then propagate to the customer’s Permissions Index, to dictate which users can access particular documents and embeddings to make future retrieval more efficient and enforce the correct access rules.
• Post-Filtering: At retrieval time, we have additional checks, like Attribute Based Access Controls (ABAC) that apply further filtering beyond the pre-filtered ReBAC rules.

The Mechanics of Relationship Based Access Control (ReBAC)

A deeper dive of how Moveworks has constructed our unified permissions platform (using OpenFGA) can be found in the blog “How we’re securing permissioned content for enterprise search”.

In summary, Moveworks aims to mirror permissions sets from various source content systems to match the OpenFGA standards using Relationship Based Access Control (ReBAC). What this means is that Moveworks wants to be able to answer:

❔Can X User do Y Operation on Z Object

To do so, Moveworks will query the source system and ingest permissions to construct a graph of the relationships from Z objects to X Users and the Y operations that link them together.

For some source systems, this task can be very straight forward to mirror. For others, Moveworks needs to do additional API calls and operations to be able to structure the graph that would allow us to easily answer this question. In general, we would query as such:

• What pieces of content Moveworks is ingesting → List of Content
• Who can access those pieces of content → List of Users / Groups / Roles that can access Z content
  • This can be broken down into multiple queries — Who can READ / who can EDIT (WRITE) / etc. → Y Operations
• Which Users are in Groups / Roles that can access Z content? → Full list of X Users

Moveworks would then preserve the relationship in the manner of: Z Content → Y Operation → X User

🔑 Moveworks is creating direct relationships from Users to Objects (Content) and cutting out the excess load of maintaining the groups/roles that may apply permissions (in systems that use ABAC, for example) by flattening out the mappings.

Incremental Ingestion Support

The only difference between doing this in a whole-sale ingestion flow versus incrementally, when updates occur, is that the operations to flatten and mirror the mappings from the source system into Moveworks need to be relatively lightweight and straightforward.

If Moveworks only needs to care about the Users / Groups / Roles and the Content Permissions that refer to them, then Moveworks can track the changes across a bounded set of record tables and track changes.

For example, Moveworks can listen for (with events/webhooks) or manually check for changes (time boxed to 15 min. or so) and see if there were changes to the:

• Content Records
• Content Permissions Records
• Group/Role Records
• User Records

Moveworks can then propagate changes from any of these changes into our ReBAC mappings.

Managed Permissions

Moveworks imports a variety of user attributes such as division, department, country code from Chat, ITSM, or IDAM integrations. These user attributes can be made available to the Moveworks Access Control Platform to be used to configure access control for resources such as forms and knowledge within Moveworks, without having to rely on a 3rd party system.

Supported Restrictions

Moveworks can enable restrictions on any user attribute imported into the Moveworks user profile, and the following attributes of an article:

1. Knowledge base of the knowledge platform. e.g:
   1. For ServiceNow, this is the "knowledge base"
   2. For Confluence, this is the "space"
   3. For Sharepoint, this is the "site"
   4. For Moveworks FAQs, this is the "Sheet tab"
2. Information on the HTML url of the article

Example restrictions

1. Only show articles from the HR ServiceNow Knowledge Base to users in specific countries:
   1. e.g: (resource.knowledge_base.$LOWERCASE() IN ["ITHELP".$LOWERCASE()]) AND (user.country_code.$LOWERCASE() IN ["Cambodia", "Thailand", "Vietnam".$LOWERCASE()])
2. Only show articles from the ITHELP Confluence space to users in the Engineering division
   1. e.g: (resource.knowledge_base.$LOWERCASE() IN ["ITHELP".$LOWERCASE()]) AND (user.division.$LOWERCASE() IN ["Engineering".$LOWERCASE()])

User Consent Permissions

Moveworks also offers the ability for Users to grant access to search across and execute workflows against their data using API calls to the source system in real-time. Connections to the source system of record that will leverage this kind of execution are called Live API Integrations.

Users are able to grant this consent to any system that a Moveworks Administrator has configured as available, through Moveworks Setup, and can be leveraged for either Enterprise Search, Creator Studio Plugins, or both.

In either case, the consent flow will leverage an oAuth2 call to the source system. For example, if a User wants to be able to search through their OneDrive content via Moveworks, they can navigate to the Enterprise Search Web interface — on the landing page, they can opt to connect and trigger the oAuth flow to OneDrive. When access is granted, Moveworks stores the token in our User Access Token store.

When the user then makes a query, we see what systems access has been granted for and retrieve the relevant User Tokens, powering API calls to search across those systems. Results are then bundled, ranked, and filtered before being returned to the user. You can learn more about how this works on our Live Search page (TBD).