Options to read file content from a Word document with restrictive Sensitivity level like Confidential

by

Summary

The core problem described is an architectural mismatch between the goal (reading content from a locally stored, protected Word document) and the tool chosen (Microsoft Information Protection SDK). The provided code attempts to use an On-Behalf-Of (OBO) authentication flow, which is strictly for server-to-server scenarios where a middle-tier service exchanges a user’s token. When run on a local desktop, this forces the application to use the machine’s environment credentials rather than the intended user context, leading to authentication failures or “Wrong Audience” errors.

Furthermore, the MIP SDK is designed for policy enforcement and label inspection, not for document content extraction. Even if authentication were solved, MIP does not provide an API to read paragraphs, tables, or text from a document; that requires the OpenXML SDK. To satisfy the security requirement of reading a “Confidential” file, the application must implement Azure Active Directory (AAD) Authentication directly to access the file, rather than relying on the MIP SDK’s token acquisition logic.

Root Cause

The failure stems from three specific implementation errors:

  • Misuse of DefaultAzureCredential in a Desktop Context: The code implements IAuthDelegate using DefaultAzureCredential. On a local machine, this chain defaults to the logged-in Windows user (via VisualStudioCredential, EnvironmentCredential, etc.). It does not honor the userEmail variable passed to FileEngineSettings. Unless the logged-in user is abcdef@mytenant.com with a valid token cached, authentication will fail.
  • Incorrect OBO (On-Behalf-Of) Logic: The developer attempted to use an App Registration with user_impersonation permissions to act on behalf of a user. OBO is a specific protocol flow used by an API or Middle-Tier service. It cannot be implemented directly in a client-side desktop application using DefaultAzureCredential without a complex, custom IAuthDelegate that manually performs the token exchange flow (Client Credential -> OBO).
  • Wrong SDK for the Task (Content vs. Label): The code attempts to use CreateFileHandlerAsync to read the file. In the MIP SDK, FileHandler is used to inspect or apply labels and rights management templates. It does not expose methods like GetText() or GetParagraphs(). The user is trying to use a governance tool (MIP) to perform a data extraction task (OpenXML).

Why This Happens in Real Systems

Developers often confuse Authentication (who you are) with Authorization (what you can do), especially regarding AAD scopes. Here is why this specific error pattern occurs in the wild:

  • “Magic” Credential Confusion: DefaultAzureCredential is powerful but opaque. Developers assume it will “just work” with the connection string or parameters provided, not realizing it prioritizes environment variables and Visual Studio logged-in users over the code-specified email address.
  • Visual Studio Interference: If a developer is running this code inside Visual Studio while logged in with their corporate account, DefaultAzureCredential silently picks up that token. When they deploy to a CI/CD pipeline or a different machine where that user isn’t logged in, the code breaks immediately.
  • Assumption that MIP = OpenXML: MIP is heavily marketed for “classifying documents.” Developers assume that because MIP can read the label of a document, it can also read the contents of a document. These are separate capabilities.

Real-World Impact

  • Runtime Authentication Failure: The application will crash or throw AuthenticationFailedException when running on a machine not logged in as the target user.
  • “Wrong Audience” Errors: If the App Registration is configured for a specific resource (e.g., https://graph.microsoft.com), but MIP requires access to a different endpoint (e.g., Azure Rights Management Service), the token acquisition will fail.
  • Data Access Violations: If the application relies on MIP to “open” the file without proper AAD authentication to the file’s storage location (even if local), it will fail. However, reading a protected document (RMS) usually requires an active authentication context to decrypt the content, which DefaultAzureCredential on a local machine often cannot provide without a specific User Interaction requirement.

Example or Code

To read the content of a file with a restrictive sensitivity label, you must use the OpenXML SDK. However, you must first have the permissions to open the file. If the file is encrypted with Azure RMS, the OpenXML SDK will fail to open it unless the application is authorized.

If the file is merely labeled (but not encrypted), or if you are running in an environment where you have the decryption rights (e.g., the logged-in user owns the file), this is how you extract text. Note: This code replaces the MIP FileHandler logic.

using DocumentFormat.OpenXml.Packaging;
using DocumentFormat.OpenXml.Wordprocessing;

public static string GetWordContent(string filePath)
{
    // Open the document. If the file is RMS encrypted and the current 
    // process identity doesn't have access, this will throw an exception.
    using (WordprocessingDocument wordDoc = WordprocessingDocument.Open(filePath, false))
    {
        Body body = wordDoc.MainDocumentPart.Document.Body;

        // Extract text from all paragraphs
        return body.InnerText;
    }
}

How Senior Engineers Fix It

Senior engineers address this by separating the Authentication Strategy from the File Parsing Strategy.

  1. Implement User-Centric Authentication:

    • Stop using DefaultAzureCredential for interactive desktop apps. Instead, use InteractiveBrowserCredential or the MSAL.NET library (PublicClientApplication).
    • This prompts the user to sign in. The resulting token is guaranteed to be for the user who logged in, satisfying the “Confidential” access requirement.

  2. Use OpenXML for Content:

    • Acknowledge that MIP is for governance, not parsing. Use DocumentFormat.OpenXml.Spreadsheet (or DocumentFormat.OpenXml.Packaging for Word) to extract data.

  3. Handle RMS Encryption (If applicable):

    • If the file is encrypted such that OpenXML cannot read it (binary corruption due to encryption), the application must use the Azure Information Protection (AIP) Unified Labeling Client or the MIP SDK File API solely to decrypt the file stream into a temporary location, then parse that temp file with OpenXML. However, the MIP SDK requires specific licensing and setup to do this.

Refactored Auth Delegate for Desktop:

public class DesktopAuthDelegate : IAuthDelegate
{
    private readonly string _clientId;
    private readonly string _tenantId;
    private readonly IPublicClientApplication _app;

    public DesktopAuthDelegate(string clientId, string tenantId)
    {
        _clientId = clientId;
        _tenantId = tenantId;
        _app = PublicClientApplicationBuilder.Create(clientId)
            .WithTenantId(tenantId)
            .WithRedirectUri("http://localhost")
            .Build();
    }

    public string AcquireToken(Identity identity, string authority, string resource, string claims)
    {
        // Ensure scopes cover Graph API and RMS
        var scopes = new[] { $"{resource}/.default" };

        // This forces an interactive browser login if not cached
        var result = _app.AcquireTokenInteractive(scopes).ExecuteAsync().Result;
        return result.AccessToken;
    }
}

Why Juniors Miss It

  • Copy-Paste Blindness: They find a sample for “Service to Service” (Daemon app) or “Middle Tier API” and paste it into a “Desktop Console App.” They fail to realize that the authentication context changes entirely between a Trusted Server (Secret) and an Untrusted Client (User).
  • Over-reliance on Generics: They see DefaultAzureCredential and think it handles every scenario. They don’t read the “Token Source Priority” documentation, which shows it never prompts the user for interactive login by default.
  • Scope of Library: They view the MIP SDK as a “File Reader” because they see it reading metadata (Labels). They do not realize that reading the actual text payload is outside the library’s documented capabilities.