mattcotterellnz / identityserver.contrib.azurekeyvaulttokensigningservice Goto Github PK

Needs a brief introduction, tutorial on how to set up Azure Key Vault for this purpose, and other relevant README things

Need to allow users to supply a primary and secondary Client Secret for the same Client ID, in order to allow key rotation without downtime.

Failed authentication will try the secondary key before throwing an exception, if supplied.

The public key needs to be retrieved from the Key Vault Key, which costs one operation. In order to cut down retrievals, the exponent and modulus are remembered so the get operation is only performed once per AzureKeyVaultTokenSigningService instance. However I suspect there may be more than one instance per application, and there are scenarios such as elastic scaling that need to be considered (support using Redis?)

Hey
I am facing the same problem you are - trying to decide between CloudHSM and Azure KeyVault as the store for the private key. I saw the work you did, and it look like a great start, but the main thing that missing here, and that I am not sure how to implement is the ISigningKeyService. The main problem is the dependency in X509Certificate2. Look like you can generate a X509Certificate2 from 'JsonWebKey' (which is what you can export from the key vault, as far as I know) but this look like very ugly code to me.
I was wondering if you have any thought regarding this problem.
Thanks,
Omer

Create a demo site running:

• IdentityServer3
• IdentityServer4

IPublicKeyProvider exposes an interface that does not disallow returning an empty list of JWKs. Currently handling this by throwing an exception of type Exception, however this is a very generic exception to throw.

Hey
Currently the project will not compile using C# 5. Also the code is dependent on CNG which is available only from .net 4.6.
Thanks
Omer

As per IdentityServer/IdentityServer3#2170, rename the project to be consistent with other contrib packages.

This is important for fault tolerance reasons, we can't have the whole application fall over if Key Vault goes down in a single region.

This will be supplied via options, and a diverse region will be encouraged. All keys in both the primary and secondary vaults will be Validation Keys, the latest enabled key in the currently active vault will be the Signing Credential for up to the cache expiry.

Currently this is being referenced directly. Should actually be using JwtSecurityTokenHandler and providing an AzureKeyVaultSignatureProviderFactory.

Having support for multiple signing keys makes rotating keys easier (automatic fallback if one key cannot be accessed anymore). Worth investigating into if this is a good idea or not.

Currently Verification costs one Key Vault operation. Verifying this is not only expensive (requires a network operation), it also costs money (verification may be called in order of magnitudes more often than signing in some scenarios).

Since we (usually) have the public key, this could feasibly be performed locally by default, with the developer optionally choosing to perform the operation through Key Vault itself.

Hey
I've noticed that in SignAsync method there there is an async call using Task.Run. As far as I know (see this SO post) this is not a good practice on a code that might run in webapi code. Also, the inner code, AzureKeyVaultSignatureProvider does call a true async function, and the current implementation hide it. It might be a good idea to create another interface which return Task for such operations.

Add support for netstandard1.6

Need to reduce the amount of copy+pasting between the two different supported versions, it's very risky.

Probably easier if we wait for RC2 to land, so we've got a common PCL that's not quite such a moving target.