Security Frame: Authentication | Mitigations
Consider using a standard authentication mechanism to authenticate to Web Application
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | N/A |
| Details | Authentication is the process where an entity proves its identity, typically through credentials, such as a user name and password. There are multiple authentication protocols available which might be considered. Some of them are listed below:
Consider using a standard authentication mechanism to identify the source process |
Applications must handle failed authentication scenarios securely
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | N/A |
| Details | Applications that explicitly authenticate users must handle failed authentication scenarios securely. The authentication mechanism must:
Test for:
|
Enable step up or adaptive authentication
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | N/A |
| Details | Verify the application has additional authorization (such as step up or adaptive authentication, via multifactor authentication such as sending OTP in SMS, email etc. or prompting for re-authentication) so the user is challenged before being granted access to sensitive information. This rule also applies for making critical changes to an account or action This also means that the adaptation of authentication has to be implemented in such a manner that the application correctly enforces context-sensitive authorization so as to not allow unauthorized manipulation by means of in example, parameter tampering |
Ensure that administrative interfaces are appropriately locked down
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | N/A |
| Details | The first solution is to grant access only from a certain source IP range to the administrative interface. If that solution wouldn't be possible then it's always recommended to enforce a step-up or adaptive authentication for logging in into the administrative interface |
Implement forgot password functionalities securely
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | N/A |
| Details | The first thing is to verify that forgot password and other recovery paths send a link including a time-limited activation token rather than the password itself. Additional authentication based on soft-tokens (e.g. SMS token, native mobile applications, etc.) can be required as well before the link is sent over. Second, you shouldn't lock out the users account whilst the process of getting a new password is in progress. This could lead to a Denial of service attack whenever an attacker decides to intentionally lock out the users with an automated attack. Third, whenever the new password request was set in progress, the message you display should be generalized in order to prevent username enumeration. Fourth, always disallow the use of old passwords and implement a strong password policy. |
Ensure that password and account policy are implemented
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | N/A |
| Details | Password and account policy in compliance with organizational policy and best practices should be implemented. To defend against brute-force and dictionary based guessing: Strong password policy must be implemented to ensure that users create complex password (e.g., 12 characters minimum length, alphanumeric and special characters). Account lockout policies might be implemented in the following manner:
To defend against attacks on default and predictable accounts, verify that all keys and passwords are replaceable, and are generated or replaced after installation time. If the application has to auto-generate passwords, ensure that the generated passwords are random and have high entropy. |
Implement controls to prevent username enumeration
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | N/A |
| Steps | All error messages should be generalized in order to prevent username enumeration. Also sometimes you can't avoid information leaking in functionalities such as a registration page. Here you need to use rate-limiting methods like CAPTCHA to prevent an automated attack by an attacker. |
When possible, use Windows Authentication for connecting to SQL Server
| Title | Details |
|---|---|
| Component | Database |
| SDL Phase | Build |
| Applicable Technologies | On-premises |
| Attributes | SQL Version - All |
| References | SQL Server - Choose an Authentication Mode |
| Steps | Windows Authentication uses Kerberos security protocol, provides password policy enforcement with regard to complexity validation for strong passwords, provides support for account lockout, and supports password expiration. |
When possible use Microsoft Entra authentication for Connecting to SQL Database
| Title | Details |
|---|---|
| Component | Database |
| SDL Phase | Build |
| Applicable Technologies | SQL Azure |
| Attributes | SQL Version - V12 |
| References | Connecting to SQL Database By Using Microsoft Entra authentication |
| Steps | Minimum version: Azure SQL Database V12 required to allow Azure SQL Database to use Microsoft Entra authentication against the Microsoft Directory |
When SQL authentication mode is used, ensure that account and password policy are enforced on SQL server
| Title | Details |
|---|---|
| Component | Database |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | SQL Server password policy |
| Steps | When using SQL Server Authentication, logins are created in SQL Server that aren't based on Windows user accounts. Both the user name and the password are created by using SQL Server and stored in SQL Server. SQL Server can use Windows password policy mechanisms. It can apply the same complexity and expiration policies used in Windows to passwords used inside SQL Server. |
Do not use SQL Authentication in contained databases
| Title | Details |
|---|---|
| Component | Database |
| SDL Phase | Build |
| Applicable Technologies | On-premises, SQL Azure |
| Attributes | SQL Version - MSSQL2012, SQL Version - V12 |
| References | Security Best Practices with Contained Databases |
| Steps | The absence of an enforced password policy might increase the likelihood of a weak credential being established in a contained database. Leverage Windows Authentication. |
Use per device authentication credentials using SaS tokens
| Title | Details |
|---|---|
| Component | Azure Event Hubs |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | Event Hubs authentication and security model overview |
| Steps | The Event Hubs security model is based on a combination of Shared Access Signature (SAS) tokens and event publishers. The publisher name represents the DeviceID that receives the token. This would help associate the tokens generated with the respective devices. All messages are tagged with originator on service side allowing detection of in-payload origin spoofing attempts. When authenticating devices, generate a per device SaS token scoped to a unique publisher. |
Enable Microsoft Entra multifactor authentication for Azure Administrators
| Title | Details |
|---|---|
| Component | Azure Trust Boundary |
| SDL Phase | Deployment |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | What is Microsoft Entra multifactor authentication? |
| Steps | multifactor authentication (MFA) is a method of authentication that requires more than one verification method and adds a critical second layer of security to user sign-ins and transactions. It works by requiring any two or more of the following verification methods:
|
Restrict anonymous access to Service Fabric Cluster
| Title | Details |
|---|---|
| Component | Service Fabric Trust Boundary |
| SDL Phase | Deployment |
| Applicable Technologies | Generic |
| Attributes | Environment - Azure |
| References | Service Fabric cluster security scenarios |
| Steps | Clusters should always be secured to prevent unauthorized users from connecting to your cluster, especially when it has production workloads running on it. While creating a service fabric cluster, ensure that the security mode is set to "secure" and configure the required X.509 server certificate. Creating an "insecure" cluster will allow any anonymous user to connect to it if it exposes management endpoints to the public Internet. |
Ensure that Service Fabric client-to-node certificate is different from node-to-node certificate
| Title | Details |
|---|---|
| Component | Service Fabric Trust Boundary |
| SDL Phase | Deployment |
| Applicable Technologies | Generic |
| Attributes | Environment - Azure, Environment - Stand alone |
| References | Service Fabric Client-to-node certificate security, Connect to a secure cluster using client certificate |
| Steps | Client-to-node certificate security is configured while creating the cluster either through the Azure portal, Resource Manager templates or a standalone JSON template by specifying an admin client certificate and/or a user client certificate. The admin client and user client certificates you specify should be different than the primary and secondary certificates you specify for Node-to-node security. |
Use Microsoft Entra ID to authenticate clients to service fabric clusters
| Title | Details |
|---|---|
| Component | Service Fabric Trust Boundary |
| SDL Phase | Deployment |
| Applicable Technologies | Generic |
| Attributes | Environment - Azure |
| References | Cluster security scenarios - Security Recommendations |
| Steps | Clusters running on Azure can also secure access to the management endpoints using Microsoft Entra ID, apart from client certificates. For Azure clusters, it is recommended that you use Microsoft Entra security to authenticate clients and certificates for node-to-node security. |
Ensure that service fabric certificates are obtained from an approved Certificate Authority (CA)
| Title | Details |
|---|---|
| Component | Service Fabric Trust Boundary |
| SDL Phase | Deployment |
| Applicable Technologies | Generic |
| Attributes | Environment - Azure |
| References | X.509 certificates and Service Fabric |
| Steps | Service Fabric uses X.509 server certificates for authenticating nodes and clients. Some important things to consider while using certificates in service fabrics:
|
Use standard authentication scenarios supported by Identity Server
| Title | Details |
|---|---|
| Component | Identity Server |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | IdentityServer3 - The Big Picture |
| Steps | Below are the typical interactions supported by Identity Server:
|
Override the default Identity Server token cache with a scalable alternative
| Title | Details |
|---|---|
| Component | Identity Server |
| SDL Phase | Deployment |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | Identity Server Deployment - Caching |
| Steps | IdentityServer has a simple built-in in-memory cache. While this is good for small scale native apps, it does not scale for mid tier and backend applications for the following reasons:
|
Ensure that deployed application's binaries are digitally signed
| Title | Details |
|---|---|
| Component | Machine Trust Boundary |
| SDL Phase | Deployment |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | N/A |
| Steps | Ensure that deployed application's binaries are digitally signed so that the integrity of the binaries can be verified |
Enable authentication when connecting to MSMQ queues in WCF
| Title | Details |
|---|---|
| Component | WCF |
| SDL Phase | Build |
| Applicable Technologies | Generic, NET Framework 3 |
| Attributes | N/A |
| References | MSDN |
| Steps | Program fails to enable authentication when connecting to MSMQ queues, an attacker can anonymously submit messages to the queue for processing. If authentication is not used to connect to an MSMQ queue used to deliver a message to another program, an attacker could submit an anonymous message that is malicious. |
Example
The <netMsmqBinding/> element of the WCF configuration file below instructs WCF to disable authentication when connecting to an MSMQ queue for message delivery.
<bindings>
<netMsmqBinding>
<binding>
<security>
<transport msmqAuthenticationMode=""None"" />
</security>
</binding>
</netMsmqBinding>
</bindings>
Configure MSMQ to require Windows Domain or Certificate authentication at all times for any incoming or outgoing messages.
Example
The <netMsmqBinding/> element of the WCF configuration file below instructs WCF to enable certificate authentication when connecting to an MSMQ queue. The client is authenticated using X.509 certificates. The client certificate must be present in the certificate store of the server.
<bindings>
<netMsmqBinding>
<binding>
<security>
<transport msmqAuthenticationMode=""Certificate"" />
</security>
</binding>
</netMsmqBinding>
</bindings>
WCF-Do not set Message clientCredentialType to none
| Title | Details |
|---|---|
| Component | WCF |
| SDL Phase | Build |
| Applicable Technologies | .NET Framework 3 |
| Attributes | Client Credential Type - None |
| References | MSDN, Fortify |
| Steps | The absence of authentication means everyone is able to access this service. A service that does not authenticate its clients allows access to all users. Configure the application to authenticate against client credentials. This can be done by setting the message clientCredentialType to Windows or Certificate. |
Example
<message clientCredentialType=""Certificate""/>
WCF-Do not set Transport clientCredentialType to none
| Title | Details |
|---|---|
| Component | WCF |
| SDL Phase | Build |
| Applicable Technologies | Generic, .NET Framework 3 |
| Attributes | Client Credential Type - None |
| References | MSDN, Fortify |
| Steps | The absence of authentication means everyone is able to access this service. A service that does not authenticate its clients allows all users to access its functionality. Configure the application to authenticate against client credentials. This can be done by setting the transport clientCredentialType to Windows or Certificate. |
Example
<transport clientCredentialType=""Certificate""/>
Ensure that standard authentication techniques are used to secure Web APIs
| Title | Details |
|---|---|
| Component | Web API |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | Authentication and Authorization in ASP.NET Web API, External Authentication Services with ASP.NET Web API (C#) |
| Steps | Authentication is the process where an entity proves its identity, typically through credentials, such as a user name and password. There are multiple authentication protocols available which might be considered. Some of them are listed below:
Links in the references section provide low-level details on how each of the authentication schemes can be implemented to secure a Web API. |
Use standard authentication scenarios supported by Microsoft Entra ID
| Title | Details |
|---|---|
| Component | Microsoft Entra ID |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | Authentication Scenarios for Microsoft Entra ID, Microsoft Entra code Samples, Microsoft Entra developer's guide |
| Steps | Microsoft Entra ID simplifies authentication for developers by providing identity as a service, with support for industry-standard protocols such as OAuth 2.0 and OpenID Connect. Below are the five primary application scenarios supported by Microsoft Entra ID:
Please refer to the links in the references section for low-level implementation details |
Override the default MSAL token cache with a distributed cache
| Title | Details |
|---|---|
| Component | Microsoft Entra ID |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | Token cache serialization in MSAL.NET |
| Steps | The default cache that MSAL (Microsoft Authentication Library) uses is an in-memory cache, and is scalable. However there are different options available that you can use as an alternative, such as a distributed token cache. These have L1/L2 mechanisms, where L1 is in memory and L2 is the distributed cache implementation. These can be accordingly configured to limit L1 memory, encrypt or set eviction policies. Other alternatives include Redis, SQL Server or Azure Comsos DB caches. An implementation of a distributed token cache can be found in the following Tutorial: Get started with ASP.NET Core MVC. |
Ensure that TokenReplayCache is used to prevent the replay of MSAL authentication tokens
| Title | Details |
|---|---|
| Component | Microsoft Entra ID |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | Modern Authentication with Microsoft Entra ID for Web Applications |
| Steps | The TokenReplayCache property allows developers to define a token replay cache, a store that can be used for saving tokens for the purpose of verifying that no token can be used more than once. This is a measure against a common attack, the aptly called token replay attack: an attacker intercepting the token sent at sign-in might try to send it to the app again (“replay” it) for establishing a new session. E.g., In OIDC code-grant flow, after successful user authentication, a request to "/signin-oidc" endpoint of the relying party is made with "id_token", "code" and "state" parameters. The relying party validates this request and establishes a new session. If an adversary captures this request and replays it, he/she can establish a successful session and spoof the user. The presence of the nonce in OpenID Connect can limit but not fully eliminate the circumstances in which the attack can be successfully enacted. To protect their applications, developers can provide an implementation of ITokenReplayCache and assign an instance to TokenReplayCache. |
Example
// ITokenReplayCache defined in MSAL
public interface ITokenReplayCache
{
bool TryAdd(string securityToken, DateTime expiresOn);
bool TryFind(string securityToken);
}
Example
Here is a sample implementation of the ITokenReplayCache interface. (Please customize and implement your project-specific caching framework)
public class TokenReplayCache : ITokenReplayCache
{
private readonly ICacheProvider cache; // Your project-specific cache provider
public TokenReplayCache(ICacheProvider cache)
{
this.cache = cache;
}
public bool TryAdd(string securityToken, DateTime expiresOn)
{
if (this.cache.Get<string>(securityToken) == null)
{
this.cache.Set(securityToken, securityToken);
return true;
}
return false;
}
public bool TryFind(string securityToken)
{
return this.cache.Get<string>(securityToken) != null;
}
}
The implemented cache has to be referenced in OIDC options via the "TokenValidationParameters" property as follows.
OpenIdConnectOptions openIdConnectOptions = new OpenIdConnectOptions
{
AutomaticAuthenticate = true,
... // other configuration properties follow..
TokenValidationParameters = new TokenValidationParameters
{
TokenReplayCache = new TokenReplayCache(/*Inject your cache provider*/);
}
}
Please note that to test the effectiveness of this configuration, sign in into your local OIDC-protected application and capture the request to "/signin-oidc" endpoint in fiddler. When the protection is not in place, replaying this request in fiddler will set a new session cookie. When the request is replayed after the TokenReplayCache protection is added, the application will throw an exception as follows: SecurityTokenReplayDetectedException: IDX10228: The securityToken has previously been validated, securityToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBPWWlKSE1iYTlnb0VLWSIsImtpZCI6Ik1uQ1......
Use MSAL libraries to manage token requests from OAuth2 clients to Microsoft Entra ID (or on-premises AD)
| Title | Details |
|---|---|
| Component | Microsoft Entra ID |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | MSAL |
| Steps | The Microsoft Authentication Library (MSAL) enables developers to acquire security tokens from the Microsoft identity platform to authenticate users and access secured web APIs. It can be used to provide secure access to Microsoft Graph, other Microsoft APIs, third-party web APIs, or your own web API. MSAL supports many different application architectures and platforms including .NET, JavaScript, Java, Python, Android, and iOS. |
MSAL gives you many ways to get tokens, with a consistent API for many platforms. There is no need to directly use the OAuth libraries or code against the protocol in your application, and can acquire tokens on behalf of a user or application (when applicable to the platform).
MSAL also maintains a token cache and refreshes tokens for you when they're close to expiring. MSAL can also help you specify which audience you want your application to sign in, and help you set up your application from configuration files, and troubleshoot your app.
Authenticate devices connecting to the Field Gateway
| Title | Details |
|---|---|
| Component | IoT Field Gateway |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | N/A |
| Steps | Ensure that each device is authenticated by the Field Gateway before accepting data from them and before facilitating upstream communications with the Cloud Gateway. Also, ensure that devices connect with a per device credential so that individual devices can be uniquely identified. |
Ensure that devices connecting to Cloud gateway are authenticated
| Title | Details |
|---|---|
| Component | IoT Cloud Gateway |
| SDL Phase | Build |
| Applicable Technologies | Generic, C#, Node.JS, |
| Attributes | N/A, Gateway choice - Azure IoT Hub |
| References | N/A, Azure IoT hub with .NET, Getting Started with IoT hub and Node JS, Securing IoT with SAS and certificates, Git repository |
| Steps |
|
Example
static DeviceClient deviceClient;
static string deviceKey = "{device key}";
static string iotHubUri = "{iot hub hostname}";
var messageString = "{message in string format}";
var message = new Message(Encoding.ASCII.GetBytes(messageString));
deviceClient = DeviceClient.Create(iotHubUri, new DeviceAuthenticationWithRegistrySymmetricKey("myFirstDevice", deviceKey));
await deviceClient.SendEventAsync(message);
Example
Node.JS: Authentication
Symmetric key
- Create an IoT hub on Azure
- Create an entry in the device identity registry
var device = new iothub.Device(null); device.deviceId = <DeviceId > registry.create(device, function(err, deviceInfo, res) {}) - Create a simulated device
var clientFromConnectionString = require('azure-iot-device-amqp').clientFromConnectionString; var Message = require('azure-iot-device').Message; var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>SharedAccessKey=<SharedAccessKey>'; var client = clientFromConnectionString(connectionString);SAS Token
- Gets internally generated when using symmetric key but we can generate and use it explicitly as well
- Define a protocol :
var Http = require('azure-iot-device-http').Http; - Create a sas token :
resourceUri = encodeURIComponent(resourceUri.toLowerCase()).toLowerCase(); var deviceName = "<deviceName >"; var expires = (Date.now() / 1000) + expiresInMins * 60; var toSign = resourceUri + '\n' + expires; // using crypto var decodedPassword = new Buffer(signingKey, 'base64').toString('binary'); const hmac = crypto.createHmac('sha256', decodedPassword); hmac.update(toSign); var base64signature = hmac.digest('base64'); var base64UriEncoded = encodeURIComponent(base64signature); // construct authorization string var token = "SharedAccessSignature sr=" + resourceUri + "%2fdevices%2f"+deviceName+"&sig=" + base64UriEncoded + "&se=" + expires; if (policyName) token += "&skn="+policyName; return token; - Connect using sas token:
Client.fromSharedAccessSignature(sas, Http);Certificates
- Generate a self signed X509 certificate using any tool such as OpenSSL to generate a .cert and .key files to store the certificate and the key respectively
- Provision a device that accepts secured connection using certificates.
var connectionString = '<connectionString>'; var registry = iothub.Registry.fromConnectionString(connectionString); var deviceJSON = {deviceId:"<deviceId>", authentication: { x509Thumbprint: { primaryThumbprint: "<PrimaryThumbprint>", secondaryThumbprint: "<SecondaryThumbprint>" } }} var device = deviceJSON; registry.create(device, function (err) {}); - Connect a device using a certificate
var Protocol = require('azure-iot-device-http').Http; var Client = require('azure-iot-device').Client; var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>x509=true'; var client = Client.fromConnectionString(connectionString, Protocol); var options = { key: fs.readFileSync('./key.pem', 'utf8'), cert: fs.readFileSync('./server.crt', 'utf8') }; // Calling setOptions with the x509 certificate and key (and optionally, passphrase) will configure the client //transport to use x509 when connecting to IoT Hub client.setOptions(options); //call fn to execute after the connection is set up client.open(fn);
Use per-device authentication credentials
| Title | Details |
|---|---|
| Component | IoT Cloud Gateway |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | Gateway choice - Azure IoT Hub |
| References | Azure IoT Hub Security Tokens |
| Steps | Use per device authentication credentials using SaS tokens based on Device key or Client Certificate, instead of IoT Hub-level shared access policies. This prevents the reuse of authentication tokens of one device or field gateway by another |
Ensure that only the required containers and blobs are given anonymous read access
| Title | Details |
|---|---|
| Component | Azure Storage |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | StorageType - Blob |
| References | Manage anonymous read access to containers and blobs, Shared Access Signatures, Part 1: Understanding the SAS model |
| Steps | By default, a container and any blobs within it might be accessed only by the owner of the storage account. To give anonymous users read permissions to a container and its blobs, one can set the container permissions to allow public access. Anonymous users can read blobs within a publicly accessible container without authenticating the request. Containers provide the following options for managing container access:
Anonymous access is best for scenarios where certain blobs should always be available for anonymous read access. For finer-grained control, one can create a shared access signature, which enables to delegate restricted access using different permissions and over a specified time interval. Ensure that containers and blobs, which might potentially contain sensitive data, are not given anonymous access accidentally |
Grant limited access to objects in Azure storage using SAS or SAP
| Title | Details |
|---|---|
| Component | Azure Storage |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | Shared Access Signatures, Part 1: Understanding the SAS model, Shared Access Signatures, Part 2: Create and use a SAS with Blob storage, How to delegate access to objects in your account using Shared Access Signatures and Stored Access Policies |
| Steps | Using a shared access signature (SAS) is a powerful way to grant limited access to objects in a storage account to other clients, without having to expose account access key. The SAS is a URI that encompasses in its query parameters all of the information necessary for authenticated access to a storage resource. To access storage resources with the SAS, the client only needs to pass in the SAS to the appropriate constructor or method. You can use a SAS when you want to provide access to resources in your storage account to a client that can't be trusted with the account key. Your storage account keys include both a primary and secondary key, both of which grant administrative access to your account and all of the resources in it. Exposing either of your account keys opens your account to the possibility of malicious or negligent use. Shared access signatures provide a safe alternative that allows other clients to read, write, and delete data in your storage account according to the permissions you've granted, and without need for the account key. If you have a logical set of parameters that are similar each time, using a Stored Access Policy (SAP) is a better idea. Because using a SAS derived from a Stored Access Policy gives you the ability to revoke that SAS immediately, it is the recommended best practice to always use Stored Access Policies when possible. |
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for