You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Our service currently uses Microsoft.Identity.ServiceEssentials (MISE) to handle AuthN and AuthZ. The MISE AzureAuthorizationModule acquires the first-party app token, which is then sent to the Remote PDP for authorization checks. We use certificates as the credentials for our first-party app.
At present, our service uses a custom certificate store to manage certificates. However, we are considering switching to Azure Key Vault (AKV) when initializing the MISE instance. The primary reason we haven't adopted AKV yet is that it doesn't align with our existing behavior. Specifically, we prefer to reload the certificate before it expires, more precisely, once the new certificate is available.
This leads us to several concerns regarding AKV, particularly in terms of how it handles Emergency Certificate Rotation (ECR). From my understanding, when using AKV, Microsoft.Identity.Web will automatically attempt to reload the certificate once it expires. If this is the case, wouldn't it result in a large number of requests to fetch the new certificate version when the current one expires? This could potentially lead to service unavailability.
We are seeking clarification on how Microsoft.Identity.Web and AKV handle ECR.
Describe the solution you'd like
We would like Microsoft.Identity.Web to support a more efficient and reliable mechanism for handling ECR when using AKV. Specifically, we need a solution that can proactively reload the certificate before it expires, or as soon as the new certificate is available, to avoid a surge of requests and potential service unavailability.
Describe alternatives you've considered
Custom Certificate Store: We have been using a custom certificate store to manage certificates, but this approach is not sustainable in the long run and may increase security risks.
Manual Certificate Reload: Manually reloading the certificate by restarting the service, but this is not an ideal solution as it requires manual intervention and may lead to downtime.
Azure Key Vault: Switching to AKV for certificate management, but we have concerns about how AKV handles ECR and the potential for a large number of requests when a certificate expires.
Additional context
We raised this request several months ago and were told that Microsoft.Identity.Web has a design for proactive certificate refresh. We would like to follow up on the status of this support.
The text was updated successfully, but these errors were encountered:
One thing to mention, we previously implemented a workaround to handle the ECR. On our side, whenever we detect a new certificate is available and its thumbprint differs from the one used to initialize the MISE host instance, we replace it with the last certificate we put in ClientCredentials. However, we noticed a change in TokenAcquisition.cs that resets all the certificates in the CredentialDescription list when encountering the IsInvalidClientCertificateOrSignedAssertionError (commit). As a result, our previous solution no longer works
I stumbled across this issue and I think the same happens when using the StoreWithDistinguishedName to fetch the certs. I'd expect it to proactively fetch the certs before they expire or cert is revoked.
How frequently would you like IdWeb to attempt to refresh, @wagnerfrancisco ? @lizMSFT : I believe you provide the certificate yourself and want to push new certs?
@jmprieur Yes, our current approach is to provide the certificate ourselves and pushing the latest certificate when it's available. However, this is a hacky solution, so we'd like to follow up whether AKV could implement a similar refresh strategy.
Is your feature request related to a problem? Please describe.
Our service currently uses Microsoft.Identity.ServiceEssentials (MISE) to handle AuthN and AuthZ. The MISE AzureAuthorizationModule acquires the first-party app token, which is then sent to the Remote PDP for authorization checks. We use certificates as the credentials for our first-party app.
At present, our service uses a custom certificate store to manage certificates. However, we are considering switching to Azure Key Vault (AKV) when initializing the MISE instance. The primary reason we haven't adopted AKV yet is that it doesn't align with our existing behavior. Specifically, we prefer to reload the certificate before it expires, more precisely, once the new certificate is available.
This leads us to several concerns regarding AKV, particularly in terms of how it handles Emergency Certificate Rotation (ECR). From my understanding, when using AKV, Microsoft.Identity.Web will automatically attempt to reload the certificate once it expires. If this is the case, wouldn't it result in a large number of requests to fetch the new certificate version when the current one expires? This could potentially lead to service unavailability.
We are seeking clarification on how Microsoft.Identity.Web and AKV handle ECR.
Describe the solution you'd like
We would like Microsoft.Identity.Web to support a more efficient and reliable mechanism for handling ECR when using AKV. Specifically, we need a solution that can proactively reload the certificate before it expires, or as soon as the new certificate is available, to avoid a surge of requests and potential service unavailability.
Describe alternatives you've considered
Additional context
We raised this request several months ago and were told that Microsoft.Identity.Web has a design for proactive certificate refresh. We would like to follow up on the status of this support.
The text was updated successfully, but these errors were encountered: