Configuring Permission in SharePoint with .NET 8 and Microsoft Graph (Azure-first)

If you need to automate permission in SharePoint reliably, use Microsoft Graph with .NET 8 and Azure-managed identities. The goal: grant site-scoped access (least privilege via Sites.Selected), verify effective roles, and perform read/write operations without client secrets.

The Problem

SharePoint permissions are often over-provisioned or managed manually. That leads to audit gaps, break-glass patterns, and production drift. You need a repeatable, least-privilege approach that grants only the required access to specific sites, automates verification, and avoids client secrets.

Prerequisites

Required tools and permissions:

• .NET 8 SDK
• Azure CLI v2.58+ (logged in as a tenant admin for one-time grants)
• Microsoft Graph application permissions consent capability (tenant admin)
• Azure subscription access to create a user-assigned managed identity (Contributor on resource group)

The Solution (Step-by-Step)

Step 1. Choose the authentication model

Use managed identity for workloads in Azure (Functions, Container Apps). This removes client secrets entirely. For CI/CD, use workload identity federation instead of secrets.

• Runtime principal: user-assigned/system-assigned managed identity
• Graph permission model: application permission Sites.Selected for the runtime principal
• Grant site-scoped roles: read or write at the specific SharePoint site level

Why Sites.Selected: it blocks blanket access (e.g., Sites.Read.All) and forces explicit grants per site.

Step 2. Infrastructure as Code (Bicep): create a user-assigned managed identity

// main.bicep
targetScope = 'resourceGroup'

// User-assigned managed identity that will call Microsoft Graph
resource uami 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = {
  name: 'sp-sites-selected-uami'
  location: resourceGroup().location
}

output uamiClientId string = uami.properties.clientId
output uamiPrincipalId string = uami.properties.principalId

After deployment, assign Microsoft Graph application permission Sites.Selected to the managed identity’s service principal. This is a one-time admin action.

# Assign Graph app role (Sites.Selected) to the managed identity service principal
# 1) Get Graph service principal (well-known)
GRAPH_SP_ID=$(az ad sp list --filter "appId eq '00000003-0000-0000-c000-000000000000'" --query "[0].id" -o tsv)

# 2) Get the Sites.Selected app role ID
SITES_SELECTED_ROLE_ID=$(az ad sp show --id $GRAPH_SP_ID --query "appRoles[?value=='Sites.Selected' && allowedMemberTypes[@]=='Application'].id" -o tsv)

# 3) Get your managed identity's service principal object id
UAMI_PRINCIPAL_ID=<uamiPrincipalId from bicep output>

# 4) Assign the app role to the managed identity
az ad sp add-approle-assignment \
  --id $UAMI_PRINCIPAL_ID \
  --principal-object-id $UAMI_PRINCIPAL_ID \
  --resource-id $GRAPH_SP_ID \
  --app-role-id $SITES_SELECTED_ROLE_ID

Admin consent is implicit when you add an app role assignment to Graph for an enterprise application (service principal). Validate in Entra ID under Enterprise applications > Your Managed Identity > Permissions.

Step 3. One-time site-scoped grant to the managed identity

Sites.Selected requires a per-site grant. Use an admin-only tool to grant read/write on a single site to the managed identity. Below is a .NET 8 minimal API you can run locally as a tenant admin via Azure CLI authentication to grant permissions. It uses DI, file-scoped namespaces, and the Microsoft Graph SDK.

using Azure.Identity;
using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Graph;
using Microsoft.Graph.Models;
using Microsoft.Kiota.Abstractions.Authentication;

namespace SharePointPermAdmin;

var builder = WebApplication.CreateBuilder(args);

// Admin credential for local, one-time operations only.
// Uses Azure CLI token of a tenant admin. No client secrets.
builder.Services.AddSingleton((sp) =>
{
    // Authenticate as the signed-in Azure CLI account
    var credential = new AzureCliCredential();

    // Adapter for Microsoft Graph SDK
    var authProvider = new TokenCredentialAuthenticationProvider(
        credential,
        // Microsoft Graph default scope for app-permission endpoints
        new[] { "https://graph.microsoft.com/.default" });

    return new GraphServiceClient(authProvider);
});

var app = builder.Build();

// Code Overview: Grants site-level permission (read or write) to a target application or managed identity
// Endpoint parameters:
//  - hostname: e.g., "contoso.sharepoint.com"
//  - sitePath: e.g., "/sites/Engineering"
//  - targetAppId: the clientId of the target app or managed identity (UAMI clientId)
//  - role: "read" or "write" (least privilege)
app.MapPost("/grant", async (GraphServiceClient graph,
    string hostname, string sitePath, string targetAppId, string role) =>
{
    // 1) Resolve the site by hostname and site path
    var site = await graph.Sites["{hostname}:{sitePath}"].GetAsync();
    if (site is null) return Results.NotFound("Site not found.");

    // 2) Prepare the permission grant
    var requestedRole = role.Equals("write", StringComparison.OrdinalIgnoreCase) ? "write" : "read";

    var permission = new Permission
    {
        // Roles supported for Sites.Selected are "read" and "write"
        Roles = new List<string> { requestedRole },
        GrantedToIdentities = new List<IdentitySet>
        {
            new IdentitySet
            {
                Application = new Identity
                {
                    // targetAppId can be the clientId of a user-assigned managed identity
                    // or an app registration clientId
                    Id = targetAppId,
                    DisplayName = "Sites.Selected App"
                }
            }
        }
    };

    // 3) Grant the permission at the site-level
    var created = await graph.Sites[site.Id].Permissions.PostAsync(permission);

    // 4) Return what was granted for audit
    return Results.Ok(new
    {
        SiteId = site.Id,
        GrantedRoles = created?.Roles,
        GrantedTo = created?.GrantedToIdentities?.Select(x => x.Application?.Id)
    });
});

app.Run();

Run this locally with an Azure CLI context that has tenant admin privileges. This API grants the site-scoped role to your managed identity (identified by its clientId). Keep this tool restricted and audit its use.

Step 4. Runtime workload: access the site using the managed identity

Your production service (Azure Functions or Container Apps) uses DefaultAzureCredential to get a token for Graph and perform read actions (if granted read) or write actions (if granted write).

using Azure.Identity;
using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Graph;
using Microsoft.Kiota.Abstractions.Authentication;

namespace SharePointRuntime;

var builder = WebApplication.CreateBuilder(args);

// Graph client using managed identity in Azure (no secrets)
// In local dev, DefaultAzureCredential falls back to Azure CLI login.
builder.Services.AddSingleton((sp) =>
{
    var credential = new DefaultAzureCredential();
    var authProvider = new TokenCredentialAuthenticationProvider(
        credential,
        new[] { "https://graph.microsoft.com/.default" });

    return new GraphServiceClient(authProvider);
});

var app = builder.Build();

// Code Overview: Example read-only endpoint listing drive root items for a given site.
// Requires the managed identity to have Sites.Selected + "read" on that site.
app.MapGet("/sites/{hostname}/{*sitePath}/drive-items", async (GraphServiceClient graph, string hostname, string sitePath) =>
{
    // 1) Resolve site by hostname and site path
    var site = await graph.Sites[$"{hostname}:{sitePath}"].GetAsync();
    if (site is null) return Results.NotFound("Site not found.");

    // 2) Read drive root items (read permission is sufficient)
    var items = await graph.Sites[site.Id].Drive.Root.Children.GetAsync();

    return Results.Ok(items?.Value?.Select(i => new { i.Id, i.Name, i.Size, i.LastModifiedDateTime }));
});

app.Run();

Step 5. Optional: strict front-end validation for an internal admin form

If you build an admin UI to call the grant API, validate inputs with Zod and strict TypeScript types.

import { z } from 'zod';

// Discriminated union for role
const RoleSchema = z.union([z.literal('read'), z.literal('write')]);

// Strict payload schema
export const GrantPayloadSchema = z.object({
  hostname: z.string().min(1).regex(/^([a-zA-Z0-9-]+)\.sharepoint\.com$/),
  sitePath: z.string().min(1).startsWith('/'),
  targetAppId: z.string().uuid(),
  role: RoleSchema
});

export type GrantPayload = z.infer<typeof GrantPayloadSchema>;

// Example safe submit
export async function submitGrant(payload: GrantPayload) {
  const parsed = GrantPayloadSchema.parse(payload); // throws on invalid input
  const res = await fetch('/grant?'
    + new URLSearchParams({
      hostname: parsed.hostname,
      sitePath: parsed.sitePath,
      targetAppId: parsed.targetAppId,
      role: parsed.role
    }), { method: 'POST' });

  if (!res.ok) throw new Error('Grant failed');
  return res.json();
}

Best Practices & Security

• Best Practice: Use Sites.Selected and grant per-site roles (read/write) instead of tenant-wide Sites.Read.All or Sites.FullControl.All.
• Best Practice: Prefer managed identity (Azure) or workload identity federation (CI/CD) over client secrets.
• Best Practice: Separate duties. Keep the grant tool under tenant admin control; the runtime app should never be able to self-elevate.
• Best Practice: Log every permission grant with who, what, when, and siteId. Store in an immutable audit store.
• Best Practice: Implement retries with exponential backoff for Graph calls and handle 429/5xx responses gracefully.
• Best Practice: Validate all inputs server-side. Reject unknown hostnames and unexpected site paths.
• Best Practice: Monitor with Microsoft 365 audit logs and alert on unexpected grants or role changes.

Minimum permissions required (explicit)

• Runtime principal (managed identity): Microsoft Graph application permission Sites.Selected.
• Admin/grant principal: Microsoft Graph application permission Sites.FullControl.All or delegated SharePoint admin role sufficient to create site-level grants via Graph.
• SharePoint site roles used for Sites.Selected: read (equivalent to site Read), write (equivalent to Edit). Grant the lowest role that satisfies requirements.

Error handling notes

• Catch GraphServiceException and map common statuses: 403 (insufficient role), 404 (site not found), 429 (throttle) with Retry-After.
• Add circuit breakers/timeouts. Do not leak raw exception messages in responses.
• Return correlation IDs in responses to aid troubleshooting.

Summary

• Grant permission in SharePoint using Sites.Selected for least privilege and auditability.
• Use managed identities or workload identity federation to remove secrets and simplify compliance.
• Automate grants and access with .NET 8, Microsoft Graph SDK, and IaC for consistent, repeatable operations.

Implementing PnP People Picker in React for SPFx: A Ready-to-Use Example with Strict TypeScript and Zod

The primary keyword pnp people picker control in react for SPfx with example sets the scope: implement a production-grade People Picker in a SharePoint Framework (SPFx) web part using React, strict TypeScript, and Zod validation. Why this matters: avoid vague selections, respect tenant boundaries and theming, and ship a fast, accessible control that your security team can approve.

The Problem

Developers often wire up People Picker quickly, then face issues with invalid selections, poor performance in large tenants, theming mismatches, and missing API permissions. The goal is a robust People Picker that validates data, performs well, and aligns with SPFx and Microsoft 365 security constraints.

Prerequisites

• Node.js v20+
• SPFx v1.18+ (React and TypeScript template)
• @pnp/spfx-controls-react v3.23.0+ (PeoplePicker)
• TypeScript strict mode enabled ("strict": true)
• Zod v3.23.8+ for schema validation
• Tenant admin rights to approve Microsoft Graph permissions for the package

The Solution (Step-by-Step)

1) Install dependencies and pin versions

npm install @pnp/spfx-controls-react@3.23.0 zod@3.23.8

Recommendation: pin versions to prevent accidental breaking changes in builds.

2) Configure delegated permissions (least privilege)

In config/package-solution.json, request the minimum Graph scopes needed to resolve people:

{
  "solution": {
    "webApiPermissionRequests": [
      { "resource": "Microsoft Graph", "scope": "User.ReadBasic.All" },
      { "resource": "Microsoft Graph", "scope": "People.Read" }
    ]
  }
}

After packaging and deploying, a tenant admin must approve these scopes. These are delegated permissions tied to the current user; no secrets or app-only access are required for the People Picker scenario.

3) Implement a strict, validated People Picker component

/* PeoplePickerField.tsx */
import * as React from "react";
import { useCallback, useMemo, useState } from "react";
import { WebPartContext } from "@microsoft/sp-webpart-base";
import { PeoplePicker, PrincipalType } from "@pnp/spfx-controls-react/lib/PeoplePicker";
import { z } from "zod";

// Define the shape we accept from People Picker selections
// The control returns IPrincipal-like objects; we validate subset we rely upon.
const PersonSchema = z.object({
  id: z.union([z.string(), z.number()]), // Graph or SP ID can be number or string
  secondaryText: z.string().nullable().optional(), // usually email or subtitle
  text: z.string().min(1), // display name
});

const SelectedPeopleSchema = z.array(PersonSchema).max(5); // enforce cardinality

export type ValidPerson = z.infer<typeof PersonSchema>;

export interface PeoplePickerFieldProps {
  context: WebPartContext; // SPFx context to ensure tenant and theme alignment
  label?: string;
  required?: boolean;
  maxPeople?: number; // override default of 5
  onChange: (people: ValidPerson[]) => void; // emits validated data only
}

// Memoized to avoid unnecessary re-renders in large forms
const PeoplePickerField: React.FC<PeoplePickerFieldProps> = ({
  context,
  label = "Assign to",
  required = false,
  maxPeople = 5,
  onChange,
}) => {
  // Internal state to show validation feedback
  const [error, setError] = useState<string | null>(null);

  // Enforce hard cap
  const personSelectionLimit = useMemo(() => Math.min(Math.max(1, maxPeople), 25), [maxPeople]);

  // Convert PeoplePicker selections through Zod
  const handleChange = useCallback((items: unknown[]) => {
    // PeoplePicker sends unknown shape; validate strictly before emitting
    const parsed = SelectedPeopleSchema.safeParse(items);
    if (!parsed.success) {
      setError("Invalid selection. Please choose valid users only.");
      onChange([]);
      return;
    }

    // Optional business rule: ensure each user has an email-like secondaryText
    const withEmail = parsed.data.filter(p => (p.secondaryText ?? "").includes("@"));
    if (withEmail.length !== parsed.data.length) {
      setError("Some selections are missing a valid email.");
      onChange([]);
      return;
    }

    setError(null);
    onChange(parsed.data);
  }, [onChange]);

  return (
    <div>
      <label>{label}{required ? " *" : ""}</label>
      {/**
       * PeoplePicker respects SPFx theme through provided context.
       * Use PrincipalType to limit search to users only, avoiding groups for clarity.
       */}
      <PeoplePicker
        context={context}
        titleText={label}
        personSelectionLimit={personSelectionLimit}
        ensureUser={true} // resolves users to the site collection to avoid auth issues
        showHiddenInUI={false}
        principalTypes={[PrincipalType.User]}
        resolveDelay={300} // debounce for performance in large tenants
        onChange={handleChange}
        required={required}
      />

      {/** Live region for accessibility */}
      <div aria-live="polite">{error ? error : ""}</div>
    </div>
  );
};

export default React.memo(PeoplePickerField);

Notes: resolveDelay reduces repeated queries while typing. principalTypes avoids unnecessary group matches unless you require them.

4) Use the field in a web part with validated submit

/* MyWebPartComponent.tsx */
import * as React from "react";
import { useCallback, useState } from "react";
import { WebPartContext } from "@microsoft/sp-webpart-base";
import PeoplePickerField, { ValidPerson } from "./PeoplePickerField";

interface MyWebPartProps { context: WebPartContext; }

const MyWebPartComponent: React.FC<MyWebPartProps> = ({ context }) => {
  const [assignees, setAssignees] = useState<ValidPerson[]>([]);
  const [submitStatus, setSubmitStatus] = useState<"idle" | "saving" | "success" | "error">("idle");

  const handlePeopleChange = useCallback((people: ValidPerson[]) => setAssignees(people), []);

  const handleSubmit = useCallback(async () => {
    try {
      setSubmitStatus("saving");
      // Example: persist only the IDs or emails to a list/Graph to avoid storing PII redundantly
      const payload = assignees.map(p => ({ id: String(p.id), email: p.secondaryText }));
      // TODO: call a secure API (e.g., SPHttpClient to SharePoint list) using current user's context
      await new Promise(r => setTimeout(r, 600)); // simulate network
      setSubmitStatus("success");
    } catch {
      setSubmitStatus("error");
    }
  }, [assignees]);

  return (
    <div>
      <h3>Create Task</h3>
      <PeoplePickerField
        context={context}
        label="Assignees"
        required={true}
        maxPeople={3}
        onChange={handlePeopleChange}
      />
      <button onClick={handleSubmit} disabled={assignees.length === 0 || submitStatus === "saving"}>
        Save
      </button>
      <div aria-live="polite">{submitStatus === "saving" ? "Saving..." : ""}</div>
      <div aria-live="polite">{submitStatus === "success" ? "Saved" : ""}</div>
      <div aria-live="polite">{submitStatus === "error" ? "Save failed" : ""}</div>
    </div>
  );
};

export default MyWebPartComponent;

5) Authentication in SPFx context

SPFx provides delegated authentication via the current user. For Microsoft Graph calls, use MSGraphClientFactory; for SharePoint calls, use SPHttpClient. You do not need to store tokens; SPFx handles tokens and consent. Avoid manual token acquisition unless implementing advanced scenarios.

6) Minimal test to validate the component contract

// PeoplePickerField.test.tsx
import React from "react";
import { render } from "@testing-library/react";
import PeoplePickerField from "./PeoplePickerField";

// Mock SPFx WebPartContext minimally for the control; provide shape your test runner needs
const mockContext = {} as unknown as any; // In real tests, provide a proper mock of the context APIs used by the control

test("renders label and enforces required", () => {
  const { getByText } = render(
    <PeoplePickerField context={mockContext} label="Assignees" required onChange={() => {}} />
  );
  expect(getByText(/Assignees/)).toBeTruthy();
});

Note: In integration tests, mount within an SPFx test harness or mock the PeoplePicker dependency. For unit tests, focus on validation logic paths invoked by onChange.

Best Practices & Security

• Least privilege permissions. Request only User.ReadBasic.All and People.Read for resolving users. Do not request write scopes unless necessary.
• Azure RBAC and Microsoft 365 roles. This scenario uses delegated permissions within Microsoft 365; no Azure subscription RBAC role is required. Users need a valid SharePoint license and access to the site. Tenant admin must approve Graph scopes. For directory-read scenarios beyond basics, Directory Readers role may be required by policy.
• PII hygiene. Persist only identifiers (e.g., user IDs or emails) rather than full profiles. Avoid logging personal data. Mask PII in telemetry.
• Performance. Use resolveDelay to debounce search. Limit personSelectionLimit to a realistic value (e.g., 3–5). Memoize the field (React.memo) and callbacks (useCallback) to reduce re-renders in complex forms.
• Accessibility. Provide aria-live regions for validation and submit status. Ensure color contrast via SPFx theming; the PeoplePicker uses SPFx theme tokens when context is provided.
• Theming. Always pass the SPFx context to ensure the control inherits the current site theme.
• Error resilience. Wrap parent forms with an error boundary to display a fallback UI if a child component throws.
• Versioning. Pin dependency versions in package.json to avoid unexpected changes. Regularly update to the latest stable to receive security fixes.
• No server-side tech references here. Entity Framework patterns such as AsNoTracking are not applicable in SPFx client-side code.

Example package.json pins

{
  "dependencies": {
    "@pnp/spfx-controls-react": "3.23.0",
    "zod": "3.23.8"
  }
}

Optional: Error boundary pattern

import React from "react";

class ErrorBoundary extends React.Component<{}, { hasError: boolean }> {
  constructor(props: {}) {
    super(props);
    this.state = { hasError: false };
  }
  static getDerivedStateFromError() { return { hasError: true }; }
  render() { return this.state.hasError ? <div>Something went wrong.</div> : this.props.children; }
}

export default ErrorBoundary;

Wrap your form: ErrorBoundary around MyWebPartComponent to ensure a graceful fallback.

Summary

• Implemented a strict, validated People Picker for SPFx with React, Zod, and tenant-aware theming via context.
• Applied least privilege delegated permissions with admin consent, clear performance tuning, and accessibility patterns.
• Hardened production readiness through validation-first design, memoization, testing hooks, and pinned dependencies.