Rediger

Del via

Access control overview

  • Artikkel

Applies to: ✅ Microsoft Fabric ✅ Azure Data Explorer

Access control is based on authentication and authorization. Each query and command on an Azure Data Explorer resource, such as a cluster or database, must pass both authentication and authorization checks.

Access control is based on authentication and authorization. Each query and command on a Fabric resource, such as a KQL database, must pass both authentication and authorization checks.

  • Authentication: Validates the identity of the security principal making a request
  • Authorization: Validates the security principal making a request is permitted to make that request on the target resource

Authentication

To programmatically authenticate, a client must communicate with Microsoft Entra ID and request an access token specific to the Kusto service. Then, the client can use the acquired access token as proof of identity when issuing requests to your database.

The main authentication scenarios are as follows:

Note

For user and application authentication, we recommend using the Kusto client libraries. If you require On-behalf-of (OBO) or Single-Page Application (SPA) authentication, you'll need to use MSAL directly as these flows aren't supported by the client libraries. For more information, see Authenticate with Microsoft Authentication Library (MSAL).

User authentication

User authentication happens when a user presents credentials to Microsoft Entra ID or an identity provider that federates with Microsoft Entra ID, such as Active Directory Federation Services. The user gets back a security token that can be presented to the Azure Data Explorer service. Azure Data Explorer determines whether the token is valid, whether the token is issued by a trusted issuer, and what security claims the token contains.

Azure Data Explorer supports the following methods of user authentication, including through the Kusto client libraries:

  • Interactive user authentication with sign-in through the user interface.
  • User authentication with a Microsoft Entra token issued for Azure Data Explorer.
  • User authentication with a Microsoft Entra token issued for another resource that can be exchanged for an Azure Data Explorer token using On-behalf-of (OBO) authentication.

Application authentication

Application authentication is needed when requests aren't associated with a specific user or when no user is available to provide credentials. In this case, the application authenticates to Microsoft Entra ID or the federated IdP by presenting secret information.

Azure Data Explorer supports the following methods of application authentication, including through the Kusto client libraries:

  • Application authentication with an Azure managed identity.
  • Application authentication with an X.509v2 certificate installed locally.
  • Application authentication with an X.509v2 certificate given to the client library as a byte stream.
  • Application authentication with a Microsoft Entra application ID and a Microsoft Entra application key. The application ID and application key are like a username and password.
  • Application authentication with a previously obtained valid Microsoft Entra token, issued to Azure Data Explorer.
  • Application authentication with a Microsoft Entra token issued for another resource that can be exchanged for an Azure Data Explorer token using On-behalf-of (OBO) authentication.

Authorization

Before carrying out an action on a resource, all authenticated users must pass an authorization check. The Kusto role-based access control model is used, where principals are ascribed to one or more security roles. Authorization is granted as long as one of the roles assigned to the user allows them to perform the specified action. For example, the Database User role grants security principals the right to read the data of a particular database, create tables in the database, and more.

The association of security principals to security roles can be defined individually or by using security groups that are defined in Microsoft Entra ID. For more information on how to assign security roles, see Security roles overview.

Group authorization

Authorization can be granted to Microsoft Entra ID groups by assigning one or more roles to the group.

When the authorization of a user or application principal is checked, the system first checks for an explicit role assignment permitting the specific action. If no such role assignment exists, the system then analyzes the principal's membership across all groups that could potentially authorize the action. If the principal is confirmed to be a member of any of these groups, the requested action is authorized. Otherwise, if the principal is not a member of any such groups, the action doesn't pass the authorization check and the action isn't allowed.

Note

Checking group memberships can be resource-intensive. Since group memberships don't change frequently, the results of membership checks are cached. The caching duration varies and is influenced by factors such as the membership result (whether the principal is a member or not), the type of principal (user or application), among others. The maximum caching duration can extend up to three hours, while the minimum duration is 30 minutes.

Related content