Microsoft SharePoint

Access Scenarios

Capacity's Answer Engine is an application in which you must identify how you'd prefer your organization's data be accessed. The application can use delegated access, acting on behalf of a signed-in user, or app-only access, acting only as the application's own identity.

View full size

In this access scenario, a user can sign into the Capacity Answer Engine application, allowing it to access the resource on behalf of the user.  Delegated access requires delegated permissions. Both the application and the user must be authorized separately to make the request. For the Capacity Answer Engine application, the correct delegated permissions are granted. For the user, the authorization relies on the privileges that the user has been granted for them to access the resource.

Understanding delegated access

In this access scenario, the Capacity Answer Engine application acts on its own with no user signed in.  App-only access uses app roles which may also be called applications permissions (when granted through consent). Administrators can grant app-only permissions by using the Azure portal or by creating grants programmatically through the Microsoft Graph API.

Understanding application-only access

Assign app roles to applications

The following documentation sets will detail which application permissions are required and how to obtain the proper consent to grant the desired access.

Access Requirements

One of the following access mechanisms are required to allow Capacity's Answer Engine to index content for search:

1. Delegated access via a service account - Requires an account within your domain to be created and shared with the Capacity team. Read access is then required to be granted to the account for the delegated sites, or sites you'd like to connect with Capacity's Answer Engine, along with the ability to consent to the application's permissions. 
   • Represents the most flexible configuration. Doesn't require an Administrator to provision an application which can have challenges with limited capabilities (e.g. user consent) or permissions management. Access to the required sites can be delegated by members of the team as needed. Requires a user consent to the Capacity Answer Engine application's required permissions.
2. App-only access (sites.read.all) - Requires an application with site.read.all permissions granted. The credentials of this application are required to be shared with the Capacity team (i.e. .Application (client) ID, Directory (tenant) ID, & Secret Value). 
   • Represents our recommended app-only configuration. Avoids the burden on an Administrator to to enable the permissions to read specific sites as with the site.selected app-only access.
3. App-only access (sites.full.control & sites.selected) - Requires two applications. One application is created for administrative purposes only and requires sites.full.control permissions granted. The first application grants these permissions to the second application. The second application requires sites.selectedpermissions granted along with the curl commands executed to grant the application access to the desired or delegated sites.  The credentials of the second application are required to be shared with the Capacity team (i.e. .Application (client) ID, Directory (tenant) ID, & Secret Value).
   • Represents the most secure and inflexible app-only configuration. Given no site access is granted to the application with sites.selected permissions, this app-only configuration requires an Administrator to enable read access to each site. Microsoft does not provide a user interface to assign this permission and is required to be executed via Postman, Terminal, or PowerShell.

Below you will find linked documentation on the configuration of each application access mechanism:

Answer Engine Azure Application Setup

For more information please reach out to the Capacity Customer Success team.

Overview of permissions and consent in the Microsoft identity platform

Common Questions

What are delegated permissions?

• Delegated permissions are used in the delegated access scenario. They're permissions that allow the application to act on a user's behalf. The application will never be able to access anything the signed in user themselves couldn't access. For example, take an application that has been granted the Files.Read.All delegated permission on behalf of the user. The application will only be able to read files that the user can personally access.

Why should I use delegated access?

• Use delegated access whenever you want to let a signed-in user work with their own resources or resources they can access.

How does delegated access work?

• The most important thing to remember about delegated access is that both the app and the signed-in user need to be properly authorized. If either the app doesn’t have the right permissions, or the user doesn’t have sufficient rights to read or modify the resource, then the call will fail.
  • App authorization - Apps are authorized by granting permissions.
  • User authorization - Users are authorized by the resource you’re calling. Resource apps may use one or more systems for user authorization. For example, SharePoint Online service checks that a user has appropriate owner or reader rights over a file before allowing that user to open it.

What are application permissions?

• Application permissions, also known as app roles, are used in the app-only access scenario, without a signed-in user present. The application will be able to access any data that the permission is associated with. For example, an application granted the Microsoft Graph API's application permission Files.Read.All will be able to read any file in the tenant using Microsoft Graph. In general, only an administrator or owner of an API's service principal can consent to application permissions exposed by that API.

When should I use application-only access?

• In most cases, application-only access is broader and more powerful than delegated access, so you should only use app-only access where needed. Application access is used in scenarios such as automation and backup. In contrast, you should never use application-only access where a user would normally sign in to manage their own resources. These types of scenarios must use delegated access to be least privileged.

How does application-only access work?

• The most important thing to remember about app-only access is that the calling app acts on its own behalf and as its own identity. There's no user interaction. If the app has been assigned to a given app role for a resource, then the app has fully unconstrained access to all resources and operations governed by that app role.

Is application consent required?

• Yes. Consent is a process where users or admins authorize an application to access a protected resource. 
  • App consent - One way that applications are granted permissions is through consent. When configuring app-only access, because application permissions are required, not delegated permissions, an admin must grant consent to use the app roles assigned to the application. 
  • User consent - User consent happens when a user attempts to sign into an application. The user provides their sign-in credentials, which are checked to determine if consent has already been granted. If no previous record of user or admin consent for the required permissions exists, the user is shown a consent prompt, and asked to grant the application the requested permissions. An admin may be required to grant consent on behalf of the user.

How do I grant application consent?

• Yes. Consent is a process where users or admins authorize an application to access a protected resource.