Transient error handling for Azure MSI authentication
Are there errors that Managed Service Identity (MSI) authentication that are transient and worthwhile retrying?
Reading through the implementation I can see HttpRequestException and Exception are absorbed by the framework and rethrown as AzureServiceTokenProviderException without an inner exception.
https://github.com/Azure/azure-sdk-for-net/blob/25adfede2b99391c29b5913fc289ff9511c9b26d/src/SdkCommon/AppAuthentication/Azure.Services.AppAuthentication/TokenProviders/MsiAccessTokenProvider.cs
I'm wondering (if any transient errors are possible), whether I'd need to inspect the exception message extracting the embedded http status code in the message and rethrow an e.g. my own AzureServiceTokenProviderTransientException capturing it in my retry logic.
My initial question is are there any known transient exceptions for MSI auth and secondly if there is any built in retry logic or recommended practices?
azure azure-active-directory azure-msi transient-failure
add a comment |
Are there errors that Managed Service Identity (MSI) authentication that are transient and worthwhile retrying?
Reading through the implementation I can see HttpRequestException and Exception are absorbed by the framework and rethrown as AzureServiceTokenProviderException without an inner exception.
https://github.com/Azure/azure-sdk-for-net/blob/25adfede2b99391c29b5913fc289ff9511c9b26d/src/SdkCommon/AppAuthentication/Azure.Services.AppAuthentication/TokenProviders/MsiAccessTokenProvider.cs
I'm wondering (if any transient errors are possible), whether I'd need to inspect the exception message extracting the embedded http status code in the message and rethrow an e.g. my own AzureServiceTokenProviderTransientException capturing it in my retry logic.
My initial question is are there any known transient exceptions for MSI auth and secondly if there is any built in retry logic or recommended practices?
azure azure-active-directory azure-msi transient-failure
add a comment |
Are there errors that Managed Service Identity (MSI) authentication that are transient and worthwhile retrying?
Reading through the implementation I can see HttpRequestException and Exception are absorbed by the framework and rethrown as AzureServiceTokenProviderException without an inner exception.
https://github.com/Azure/azure-sdk-for-net/blob/25adfede2b99391c29b5913fc289ff9511c9b26d/src/SdkCommon/AppAuthentication/Azure.Services.AppAuthentication/TokenProviders/MsiAccessTokenProvider.cs
I'm wondering (if any transient errors are possible), whether I'd need to inspect the exception message extracting the embedded http status code in the message and rethrow an e.g. my own AzureServiceTokenProviderTransientException capturing it in my retry logic.
My initial question is are there any known transient exceptions for MSI auth and secondly if there is any built in retry logic or recommended practices?
azure azure-active-directory azure-msi transient-failure
Are there errors that Managed Service Identity (MSI) authentication that are transient and worthwhile retrying?
Reading through the implementation I can see HttpRequestException and Exception are absorbed by the framework and rethrown as AzureServiceTokenProviderException without an inner exception.
https://github.com/Azure/azure-sdk-for-net/blob/25adfede2b99391c29b5913fc289ff9511c9b26d/src/SdkCommon/AppAuthentication/Azure.Services.AppAuthentication/TokenProviders/MsiAccessTokenProvider.cs
I'm wondering (if any transient errors are possible), whether I'd need to inspect the exception message extracting the embedded http status code in the message and rethrow an e.g. my own AzureServiceTokenProviderTransientException capturing it in my retry logic.
My initial question is are there any known transient exceptions for MSI auth and secondly if there is any built in retry logic or recommended practices?
azure azure-active-directory azure-msi transient-failure
azure azure-active-directory azure-msi transient-failure
edited Nov 12 '18 at 9:42
Alex KeySmith
asked Nov 12 '18 at 9:31
Alex KeySmithAlex KeySmith
10.4k450113
10.4k450113
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
There error codes that MSI returns are documented here.
AzureServiceTokenProvider does include the exception details for cases where the HTTP response was not successful, so error codes like 404, 429, 500, will be included in the exception, along with an exception message. The exceptions that are absorbed are when the HTTP response was not received, e.g. when there is no MSI endpoint. The relevant code is here.
There is a retry logic recommended in the MSI documentation here. I have added a GitHub issue to implement this retry logic in the App Authentication library.
Thanks Varun, that's an excellent resource for the MSI resource code, I find researching MSI tricky, as the documentation sometimes is under VM, sometimes AD, sometimes KeyVault. Ah yes I did spot that the status code gets written into the exception, but the trouble is that it is in the message text rather than a exception property to prone to breaking changes if the exception message format changed. Thanks for raising the github ticket, I'll add some thoughts to it.
– Alex KeySmith
Nov 14 '18 at 9:55
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53259254%2ftransient-error-handling-for-azure-msi-authentication%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
There error codes that MSI returns are documented here.
AzureServiceTokenProvider does include the exception details for cases where the HTTP response was not successful, so error codes like 404, 429, 500, will be included in the exception, along with an exception message. The exceptions that are absorbed are when the HTTP response was not received, e.g. when there is no MSI endpoint. The relevant code is here.
There is a retry logic recommended in the MSI documentation here. I have added a GitHub issue to implement this retry logic in the App Authentication library.
Thanks Varun, that's an excellent resource for the MSI resource code, I find researching MSI tricky, as the documentation sometimes is under VM, sometimes AD, sometimes KeyVault. Ah yes I did spot that the status code gets written into the exception, but the trouble is that it is in the message text rather than a exception property to prone to breaking changes if the exception message format changed. Thanks for raising the github ticket, I'll add some thoughts to it.
– Alex KeySmith
Nov 14 '18 at 9:55
add a comment |
There error codes that MSI returns are documented here.
AzureServiceTokenProvider does include the exception details for cases where the HTTP response was not successful, so error codes like 404, 429, 500, will be included in the exception, along with an exception message. The exceptions that are absorbed are when the HTTP response was not received, e.g. when there is no MSI endpoint. The relevant code is here.
There is a retry logic recommended in the MSI documentation here. I have added a GitHub issue to implement this retry logic in the App Authentication library.
Thanks Varun, that's an excellent resource for the MSI resource code, I find researching MSI tricky, as the documentation sometimes is under VM, sometimes AD, sometimes KeyVault. Ah yes I did spot that the status code gets written into the exception, but the trouble is that it is in the message text rather than a exception property to prone to breaking changes if the exception message format changed. Thanks for raising the github ticket, I'll add some thoughts to it.
– Alex KeySmith
Nov 14 '18 at 9:55
add a comment |
There error codes that MSI returns are documented here.
AzureServiceTokenProvider does include the exception details for cases where the HTTP response was not successful, so error codes like 404, 429, 500, will be included in the exception, along with an exception message. The exceptions that are absorbed are when the HTTP response was not received, e.g. when there is no MSI endpoint. The relevant code is here.
There is a retry logic recommended in the MSI documentation here. I have added a GitHub issue to implement this retry logic in the App Authentication library.
There error codes that MSI returns are documented here.
AzureServiceTokenProvider does include the exception details for cases where the HTTP response was not successful, so error codes like 404, 429, 500, will be included in the exception, along with an exception message. The exceptions that are absorbed are when the HTTP response was not received, e.g. when there is no MSI endpoint. The relevant code is here.
There is a retry logic recommended in the MSI documentation here. I have added a GitHub issue to implement this retry logic in the App Authentication library.
answered Nov 12 '18 at 20:29
Varun - MSFTVarun - MSFT
1463
1463
Thanks Varun, that's an excellent resource for the MSI resource code, I find researching MSI tricky, as the documentation sometimes is under VM, sometimes AD, sometimes KeyVault. Ah yes I did spot that the status code gets written into the exception, but the trouble is that it is in the message text rather than a exception property to prone to breaking changes if the exception message format changed. Thanks for raising the github ticket, I'll add some thoughts to it.
– Alex KeySmith
Nov 14 '18 at 9:55
add a comment |
Thanks Varun, that's an excellent resource for the MSI resource code, I find researching MSI tricky, as the documentation sometimes is under VM, sometimes AD, sometimes KeyVault. Ah yes I did spot that the status code gets written into the exception, but the trouble is that it is in the message text rather than a exception property to prone to breaking changes if the exception message format changed. Thanks for raising the github ticket, I'll add some thoughts to it.
– Alex KeySmith
Nov 14 '18 at 9:55
Thanks Varun, that's an excellent resource for the MSI resource code, I find researching MSI tricky, as the documentation sometimes is under VM, sometimes AD, sometimes KeyVault. Ah yes I did spot that the status code gets written into the exception, but the trouble is that it is in the message text rather than a exception property to prone to breaking changes if the exception message format changed. Thanks for raising the github ticket, I'll add some thoughts to it.
– Alex KeySmith
Nov 14 '18 at 9:55
Thanks Varun, that's an excellent resource for the MSI resource code, I find researching MSI tricky, as the documentation sometimes is under VM, sometimes AD, sometimes KeyVault. Ah yes I did spot that the status code gets written into the exception, but the trouble is that it is in the message text rather than a exception property to prone to breaking changes if the exception message format changed. Thanks for raising the github ticket, I'll add some thoughts to it.
– Alex KeySmith
Nov 14 '18 at 9:55
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53259254%2ftransient-error-handling-for-azure-msi-authentication%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown