While implementing secure app model, we have stored the refresh token in azure key vault as a secret. While reconsent we delete that refresh token and again put the new refresh token.
Previously in azure key vault soft delete was not mandatory,so things were working fine. Now in azure key vault soft delete is mandatory so when I delete the old secret and set new secret with same name I am getting exception "Secret already present with deleted state".
As a solution now after delete secret I call purgeSecret to permanently delete it, but there is again a new problem.
Before purging we need to wait around 20 seconds so that deletedSecret call works properly else purgeSecret throws exception that "Secret is being deleted". and also to make purge successfull we again need to wait for around 10-15 seconds after purge call.
So total aroung 35 seconds we need to wait before I completely remove the old secret and then only I can set new secret.
As per our requirement, we can not wait this much amount of time, and we can not update the secret.
Is there a solution for this problem?
instead of implementing a wait, can you implement retry in your code logic that handles the exception and then tries again? There will still be a delay, but it shouldn't take 35 seconds to complete.
Related
Suppose I have this scenario where I created a signed URL to GCP object using the private key of the service account using the following command.
$ gsutil signurl -d 10m <private-key> gs://<bucket>/<obj>
Due to some reasons, I don't want to give this signurl ie., I want to revoke access.
I tried this, by limiting the duration to 0s. But the issue is for every time we run the gsutil signurl command new URL will be generated. Therefore the former one will still be accessible, in my case.
$ gsutil signurl -d 0s <private-key> gs://<bucket>/<obj>
Solutions that I can think of is,
Remove the role of "Storage Object Viewer" to the service account (OR)
Regenerate the JSON private key (OR)
Delete this particular service account.
Kindly assist me if there are any better ways using gsutil to revoke the signed url and correct me if my solutions are apt in this scenario.
You would need to delete the service account key which could have a several minute delay and would also invalidate other signed URLs.
Validation of signed URLs is via the public key and timestamp. If the timestamp has not expired, all that is left is to delete the public key which requires deleting the service account's private key.
In the event that the Signed URL was generated by the Google Managed service account key, then you must delete the service account.
According to GCStorage docs, you have to wait for expiration time or renewing service account. (https://cloud.google.com/storage/docs/access-control/signed-urls#should-you-use)
But those does not meet my requirement. So my workaround is just rename the object. After renaming, the old signed url will immediately not work anymore.
(be aware of performance of rename operation. GCS docs states that it needs to copy then delete which is slow when processing large file. But in practice, looks like GCS just edits the file metadata to rename files in same bucket. I tried rename/move large file (1GB) in same bucket and it's immediate.
Another issue is loosing original filename. I can think of some solutions such as storing original filename in cloud storage file's metadata or you can have a separate database (such as mysql) for mapping original filename to corresponding storage filename.
)
Does Azure Key Vault purge expired versions automatically so it does not get returned from get key versions?
Background:
We plan to use Azure Key Vault certificates with a 2 month rotation. So, we will set ValidityInMonths to 2 and RenewAtNumberOfDaysBeforeExpiry to 3 or so. The reason for the short rotation is that it will be used for asymetric signing.
We need to make the public keys available from an API, so we will call get key versions.
My concern is that the number of versions will keep growing every 2 months.
No, the process is not automatic. To permanently delete a secret First a user must delete the object, which puts it into the soft-deleted state. Second, a user must purge the object in the soft-deleted state. The purge operation requires additional access policy permissions.
Note: Soft delete is Enabled by by default.
You can find more information here Azure Key Vault soft-delete overview
I have a Service Connection which is being used for Pipelines in Azure DevOps. It was created by another user some time ago. Recently it expired and would not allow me to change the username it was associated with. So I deleted that Service Connection and created a new one, and it took me a lot of time to modify each Pipeline where it was being used.
I have two questions.
Is it possible to change the creator name of the Service Connection?
If not, is there any other way to reuse an existing Service Connection after its secret expires?
Thanks in advance.
I just got stuck in the same position trying to manually update the connection with a new client secret. Here's what worked for me:
From the DevOps Service Connection | Click Manage Service Principal
Then on the service principal | Certificates & Secrets
Create a "New Client Secret"
Delete the expired secret
Return to the DevOps Service Connection
Click Edit - click the verify button. It should tell you the client certificate has expired
Now you need to make a meaningless change and save it. I just type a character in to the optional description and save.
Now edit again and click verify, it will now pick up the new client secret and all is happy. Just go delete the meaningless character you typed into the description and click save.
Defining service connection you can pick a name what you want. So in your case you can reuse old name to minimize your work.
If you ahve already define service connection you can change a name using REST API:
PUT https://dev.azure.com/{organization}/{project}/_apis/serviceendpoint/endpoints/{endpointId}?api-version=5.1-preview.2
You can also edit it from the poertal:
and then:
Assuming you are using automatic authentication method. Automatic configured service connection does't allow updating the connection name or other information. You could try manual authentication method or Managed identity.
I had a similar issue that I couldn't edit an Azure RM Service Connection that had an expired client credential. However, turning off "New service connections experience" in the Preview features blade made it possible to update using the old service connection dialog.
As the title says I'm currently having an issue where the following piece of code take 20+ seconds to execute.
var azureServiceTokenProvider = new AzureServiceTokenProvider();
var keyVaultClient = new KeyVaultClient(
new KeyVaultClient.AuthenticationCallback(azureServiceTokenProvider.KeyVaultTokenCallback));
var secret = await keyVaultClient.GetSecretAsync(vaultBaseUrl, secretName).ConfigureAwait(false);
The Secret is read eventually but I feel this is an excessive amount of time to wait. I have yet to find anyone with a similar issue.
First time using Key Vault, am I possibly not accessing it correctly?
I had the same issue (on my development machine) and the reason was, that AzureServiceTokenProvider seems first to try a local url's that time out which is probably the better setting when running on Azure but not for local development.
The solution for me was to set the environment variable AzureServicesAuthConnectionString to the value RunAs=Developer; DeveloperTool=VisualStudio on my dev machine.
See also this github issue https://github.com/Azure/azure-sdk-for-net/issues/4645
Try starting the stopwatch after you retrieve your access token from AAD and ending it once you retrieve the secret. I suspect the delay is during the retrieval of the token.
Personally I found it was quicker to just get the token yourself when I created an app that used Azure APIs.
The SLA for Azure Key Vault Service is supposed to be much better
than what you're observing here. I mention it here because if all
else fails, you could take this up with Microsoft Support and they
should be able to help.
SLA for Key Vault
We guarantee that we will process Key Vault transactions within 5
seconds at least 99.9% of the time.
Check which region did you create your Key Vault in? Is your application (where you're accessing it from) in a completely different region by any chance?
We are using Oauth2 with Azure. And by default server returns token with an hour interval for expiration. Is there any way change expiration interval?
It is now possible to configure the token lifetime. You can read more here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token-lifetimes.
Remark: This feature is in preview and will not go to production in this way. The following header is also placed on the documentation link I mentioned above.
After hearing from customers during the preview, we're planning to replace this functionality with a new feature in Azure Active Directory Conditional Access. Once the new feature is complete, this functionality will eventually be deprecated after a notification period. If you use the Configurable Token Lifetime policy, be prepared to switch to the new Conditional Access feature once it's available.
Original answer:
Currently there is no way to change the expiration interval. These are the current expiration times.
Access tokens last 1 hour
Refresh tokens last for 14 days, but
If you use a refresh token within those 14 days, you will receive a new one with a new validity window shifted forward of another 14 days. You can repeat this trick for up to 90 days of total validity, then you’ll have to reauthenticate
Refresh tokens can be invalidated at ANY time, for reasons independent from your app (e.g. user changes password). Hence you should NOT take a dependency on the above in your code – your logic should always assume that the refresh token can fail at any time
Refresh tokens issues for guest MSA accounts last only 12 hours
Source: http://www.cloudidentity.com/blog/2015/03/20/azure-ad-token-lifetime/ and also my own experiences.
You have to use power shell to perform 2 steps as below:
Create new policy. This policy sets timeout 2 hours
New-AzureADPolicy -Definition #('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"02:00:00","MaxAgeSessionSingleFactor":"02:00:00"}}') -DisplayName "MyWebPolicyScenario" -IsOrganizationDefault $false -Type "TokenLifetimePolicy"
Apply this policy to your website
Add-AzureADServicePrincipalPolicy -Id <ObjectId of the ServicePrincipal> -RefObjectId <ObjectId of the Policy>
Note:
In order to get ObjectId of the ServicePrincipal, run this command: Get-AzureADServicePrincipal
To get ObjectId of the Policy, run this command: Get-AzureADPolicy
For more detail you can refer to this document: https://learn.microsoft.com/en-us/azure/active-directory/active-directory-configurable-token-lifetimes
Assuming you're talking about Azure AD, AFAIK it is not possible to do so.
However, in the response along with token you get back a refresh token as well that can be used to get a new token. What you can do is cache the refresh token and expiry time and before making a request you can check if the token has expired (or about to expire). In that case you make use of this refresh token to get a new token and then make your request.