@Rocky we will imersonate user from superset so that will require to store user name in starrocks and this is also email id not allowed and finally authorize to ranger ?

To implement user impersonation from Apache Superset to StarRocks with Apache Ranger authorization, you need to address the naming conflict between email IDs and StarRocks username constraints. 1. Username Constraints in StarRocks As you noted, StarRocks usernames are strictly limited. According to the official documentation, names for objects like usernames can only consist of digits (0-9), letters (a-z or A-Z), and underscores (_). * Emails are not allowed: Characters like

@

and

.

are prohibited in StarRocks usernames. * Workaround: You must map your email IDs to valid StarRocks usernames. Common strategies include using the email prefix (e.g.,

john

for

<mailto:john@example.com|john@example.com>

) or replacing special characters with underscores (e.g.,

john_example_com

). 2. Impersonation from Superset Superset supports user impersonation, which allows it to connect to StarRocks as a service user (e.g.,

superset_admin

) and then switch the execution context to the logged-in Superset user. * Superset Feature Flag: Superset has introduced a feature flag

IMPERSONATE_WITH_EMAIL_PREFIX

. When enabled, Superset will use only the part before the

@

as the username for impersonation. This directly solves the character constraint issue for email IDs. * StarRocks Privilege: The service user used by Superset must have the

IMPERSONATE

privilege on the target users:

sql
    GRANT IMPERSONATE ON USER 'target_user'@'%' TO USER 'superset_admin'@'%';

* Execution: Superset will then issue an

EXECUTE AS

statement at the start of the session:

sql
    EXECUTE AS 'target_user' WITH NO REVERT;

3. Authorization with Apache Ranger Once the session user is switched via impersonation, StarRocks will use that identity for authorization. * Integration: You must set

access_control = ranger

in your

fe.conf

and configure the StarRocks-Ranger plugin. * User Mapping: Ensure that the usernames you have mapped in StarRocks (e.g., the email prefixes) match exactly with the usernames defined in your Apache Ranger policies. Ranger will receive the StarRocks "session user" name to perform permission checks. * Virtual Users: If you use StarRocks Security Integration (e.g., LDAP or JWT), StarRocks creates "virtual users" for the session. Even in this case, for Ranger authorization to work, the authenticated principal must correspond to a user or group that Ranger recognizes. Summary of Workflow 1. Map Users: Decide on a mapping (e.g., email prefix) and ensure these users exist in both StarRocks (or are valid via LDAP) and Apache Ranger. 2. Grant Impersonate: Grant the

IMPERSONATE

privilege to your Superset connection user. 3. Configure Superset: Enable

IMPERSONATE_WITH_EMAIL_PREFIX

in Superset if your identities are email-based. 4. Ranger Policies: Create policies in Ranger using the mapped usernames (prefixes) to control access to databases and tables. For detailed steps on the Ranger plugin setup, refer to the Manage permissions with Apache Ranger documentation. References • administration/user_privs/authentication/security_integration.md