corvus-dotnet / corvus-dotnet/Corvus.Identity

Should we remove MSI terminology?

Open
#12 2 comments 0 reactions 1 assignee Claimed by @idg10 View on GitHub
Dominant language
C#
Stars
2
Forks
0
PR merge metrics
No merged PRs in 30d

Description

The term "MSI" (Managed Service Identity) crops up in various places in this library. This is no longer the preferred term—Microsoft now calls these things Managed Identities, largely to avoid confusion with the file extension for Windows Installer files (`.msi`), which tended to make it hard to search for anything on Managed Service Identities.

We should probably move away from the old name now before anything much depends on us.

The biggest issue here is that it's actually part of the library name. In fact, the current name seems to imply some structure that isn't there. Right now, it's:

`Corvus.Identity.ManagedServiceIdentity.ClientAuthentication`

The principal abstraction here is `IServiceIdentityTokenSource`, which suggests a slightly better name would be:

`Corvus.Identity.ServiceIdentity.ClientAuthentication`

because the `IServiceIdentityTokenSource` abstraction promises only to provide a tokens enabling a service to identify itself when acting as a client of other services. There's nothing in that abstraction that requires the identity to be an Azure Managed Identity. (In fact, the point is that code using this shouldn't have any preconceptions about how the identity is established.)

The remaining question then is whether the implied existence of other ``Corvus.Identity.ServiceIdentity.Something` libraries is misleading. There are none. Might there be? Are there use cases for a service identity besides the service being able to authenticate itself as a client? Or is that implicit in the idea of a service identity? In which case, should this really be:

`Corvus.Identity.ServiceIdentity`

And the final question is whether it's right to have the `AzureServiceTokenProvider`-based provider baked into the generic-sounding library. This library currently defines both a general-purpose abstraction, and also an Azure-specific implementation of that. The presence of the latter is actually an argument in favour of the current name, but an obsessively-factored-out setup might look like this:

| Library | Purpose |
| --- | --- |
| `Corvus.Identity.ServiceIdentity` | Just the `IServiceIdentityTokenSource` abstraction |
| `Corvus.Identity.ServiceIdentity.AzureManagedIdentity` | The `AzureServiceTokenProvider`-based implementation of `IServiceIdentityTokenSource` |

Or those could be `Corvus.Identity.ServiceIdentity.ClientAuthentication` and `Corvus.Identity.ServiceIdentity.ClientAuthentication.AzureManagedIdentity` respectively.

But is that splitting things up into unnecessarily tiny pieces?

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.