A plug-in's managed identity, on Linux, with no secret anywhere

We had a sandboxed Dataverse plug-in that needed to call an API of ours with a token, and we did not want a client secret sitting in Dataverse. Managed identity is the supported answer. Two facts decided how long it took.

The subject is the code-signing certificate

The federated credential a plug-in's managed identity uses derives its subject from the assembly's Authenticode code-signing certificate, not from the strong-name key. So the dll has to be Authenticode-signed before pac managed-identity configure-fic can compute a subject at all. This is on the Learn page, and it is easy to read past, because in every other .NET context the signing that matters to the platform is the strong name.

The practical consequence is a signer on whatever machine builds the assembly. On Linux that is osslsigncode. jsign needs a JVM, and the dotnet sign tool is Windows-only because it calls into kernel32.dll. Keep the certificate: the subject is a hash of its DN, so regenerating it invalidates the credential you already registered.

The Linux caveat was stale

The documentation carried a caveat that the CLI's managed-identity verbs do not work on Linux. On pac 2.9.3 they do. create, configure-fic and show-fic all ran and produced the right records: the managedidentity row linked to the plug-in assembly, and the federated credential written onto the app registration with the subject computed from the signed dll.

What it buys

The plug-in acquires its token through IManagedIdentityService. There is no secret in the plug-in, none in the assembly, and none in a Dataverse configuration record. We proved it end to end: a custom API call ran the plug-in in the sandbox, it exchanged the federated credential for a token, called our API, and returned rows.