2

I have a web application generating user-delegated SAS tokens authorized by the managed identity for the app.

I want to be able to monitor who uses the tokens, so I added a Correlation Id in the scid field of the token.

However, this does not show up in the logs the way I hoped it would: enter image description here

Am I misunderstanding how this is supposed to work? I thought I could (a) generate a GUID, (b) log it in the application, (c) include it in the SAS token, and (d) look it up in the Log Analytics for the Storage Account. Instead the Storage Account log generates its own CorrelationId and my scid parameter is nowhere to be found, other than in the SAS token itself.

ennui
  • 73
  • 5

2 Answers2

0

AFAIK Correlation Id is the unique identifier (GUID). This will be autogenerated for every request that server receives.

  • Correlation ID will generate whenever there is operations on storage account. This is mainly used for logging storage logs.
  • As mentioned in MS document The signedCorrelationId (scid) field specifies a correlation ID that may be used to correlate the storage audit logs with the audit logs that are used by the principal that generates and distribute. This is a part of SAS token and used for correlating logs for both local and audit.
  • So even when you set correlation ID in scid parameter it will not reflect in correlation ID because that is autogenerated for each request sent to server.
  • If you want to track who is using tokens, I will suggest you add custom properties like user id and email id.
  • Reference MS document
vijaya
  • 1,525
  • 1
  • 2
  • 6
  • Thanks for the answer. I am sorry, but this seems inconsistent / confusing to me. 1. If the `scid` parameter is generated by server and cannot be set in the token, why is it documented as a token field? Why does the Azure Storage SDK allow me to set it manually if it has no effect? 2. If this is really the case, how do I find the autogenerated correlationId in the service principal logs? The whole point is to correlate, but if I cannot set and log it in the application, then how can I correlate what's in the storage logs? 3. Are user or email ID valid fields of a SAS token? – ennui Mar 03 '23 at 08:06
  • 1.Because it is a legitimate field that can be included in an SAS token, the signedCorrelationId (scid) field is described as a token field. Although you correctly highlighted that it won't take the place of the automatically generated Correlation ID, you can manually set it in your application code using the Azure Storage SDK. It is part of the SAS token because it enables you to specify a unique correlation ID for use in correlation; however, it is not meant to take the place of the server-generated correlation ID. – vijaya Mar 03 '23 at 12:11
  • 3.A SAS token cannot contain the fields user or email ID. SAS tokens do not include user-specific information and are only meant to be used to grant temporary access to Azure Storage resources. You would need to utilise other authentication methods, such as Azure Active Directory, OAuth, or custom authentication techniques, to keep track of who is using the SAS tokens. By employing these techniques, you might recognise the user or programme using the SAS token and record that information in the log. – vijaya Mar 03 '23 at 12:13
  • But if the `scid` field is a legitimate field which can be set as a part of the SAS token, then where can I find that field in the Storage logs? That is the question. Or do I have to parse it myself from the URI? – ennui Mar 04 '23 at 13:35
  • The signedCorrelationId property from the scid field will appear in the Storage logs if you include it in the SAS token. It is located in the log entry's Properties field. – vijaya Mar 06 '23 at 07:58
0

The correlationId in the logs is for GetBlob request. The correlation id for the SAS generator is to identify a SAS when a SAS is generated or distributed. This is the "scid" in the signed fields, so in storage audit logs, users can correlate a SAS access with the person who received the SAS from the resource url that includes sas.

It maps to: Storage Analytics log format (REST API) - Azure Storage | Microsoft Docs string The complete URL of the request, in quotes. "https://myaccount.blob.core.windows.net/mycontainer/2025c44c-d25e-42bf-8507-7a5ca4faa034?timeout=30000"

SumanthMarigowda-MSFT
  • 1,920
  • 9
  • 14
  • Just to be clear: are you saying that the `scid` in the signed fields is not recorded as a field in storage logs but rather needs to be parsed out of the request URL? – ennui Mar 15 '23 at 09:21
  • Yes, correct- it needs to be parsed out of the RequestUrl field in the logs. – SumanthMarigowda-MSFT Mar 20 '23 at 16:23