Access control overview

Applies to: ✅ Microsoft Fabric ✅ Azure Data Explorer

Access control is based on authentication and authorization. Each query and command on a Fabric resource, such as a 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:

• User authentication: Used to verify the identity of human users.
• Application authentication: Used to verify the identity of an application that needs to access resources without human intervention by using configured credentials.
• On-behalf-of (OBO) authentication: Allows an application to exchange a token for said application with a token to access a Kusto service. This flow must be implemented with MSAL.
• Single page application (SPA) authentication: Allows client-side SPA web applications to sign in users and get tokens to access your database. This flow must be implemented with MSAL.

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 must use MSAL directly as the client libraries don't support these flows. 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.

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.

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 checking authorization for a user or application principal, the system first looks for an explicit role assignment that permits the specific action. If the role assignment doesn't exists, then the system checks the principal's membership in all groups that could authorize the action.

If the principal is a member of a group with appropriate permissions, the requested action is authorized. Otherwise, the action doesn't pass the authorization check and is disallowed.

Note

Checking group memberships can be resource-intensive. Since group memberships don’t change frequently, the membership check results are cached. The caching duration varies and determines how quickly changes to group memberships are updated. Adding a user to a group can take up to 30 minutes to propagate. Removing a user from a group can take up to three hours.

Force group membership refresh

Principals can force a refresh of group membership information. This capability is useful in scenarios where just-in-time (JIT) privileged access services, such as Microsoft Entra Privileged Identity Management (PIM), are used to obtain higher privileges on a resource.

Refresh for a specific group

Principals can force a refresh of group membership for a specific group. However, the following restrictions apply:

• A refresh can be requested up to 10 times per hour per principal.
• The requesting principal must be a member of the group at the time of the request.

The request results in an error if either of these conditions aren't met.

To reevaluate the current principal's membership of a group, run the following command:

.clear cluster cache groupmembership with (group='<GroupFQN>')

Use the group's fully qualified name (FQN). For more information, see Referencing Microsoft Entra principals and groups.

Refresh for other principals

A privileged principal can request a refresh for other principals. The requesting principal must have AllDatabaseMonitor access for the target service. Privileged principals can also run the previous command without restrictions.

To refresh another principal’s group membership, run the following command:

In the following command, replace <PrincipalFQN> with your own principal fully qualified name (FQN) and <GroupFQN> with your own group FQN. For more information, see Referencing Microsoft Entra principals and groups.

.clear cluster cache groupmembership with (principal='<PrincipalFQN>', group='<GroupFQN>')

Related content

• Understand Kusto role-based access control.
• For user or application authentication, use the Kusto client libraries.
• For OBO or SPA authentication, see How to authenticate with Microsoft Authentication Library (MSAL).
• For referencing principals and groups, see Referencing Microsoft Entra principals and groups.