This is a well-known limitation with embedding and composite models that trips up a lot of developers. Let me break down each of your three scenarios:
Scenario 1 — RLS on downstream (child) composite dataset → token fails
This is by design. When generating an embed token with effective identity (GenerateTokenRequestV2), the RLS identity must be specified against the report's direct dataset — and for composite models, if that dataset references another dataset via DirectQuery, the embed token API doesn't support applying effective identity to the downstream/child dataset directly. The error message is essentially telling you that the datasource type (another Power BI dataset in composite mode) can't be the target of an embed token identity.
Scenario 2 — RLS on upstream (parent) dataset → token works but no data
This is the trickier one. The embed token generates fine because you're correctly targeting the upstream dataset. But no data shows because the service principal or master account used to generate the token needs explicit access to the upstream dataset too. In composite embedding scenarios, you must include both datasets in your GenerateTokenRequestV2 call — the report's dataset AND the upstream dataset it queries — and provide the effective identity for the upstream one.
Your token generation request should look like this:
json{
"reports": [{ "id": "<report-id>" }],
"datasets": [
{ "id": "<child-dataset-id>" },
{
"id": "<parent-dataset-id>",
"xmlaPermissions": "ReadOnly",
"effectiveIdentity": {
"username": "user@domain.com",
"roles": ["YourRLSRole"],
"datasets": ["<parent-dataset-id>"]
}
}
]
}
The key things to check: the service principal must have at least Build permission on the upstream dataset, both dataset IDs must be included in the datasets array, and the effectiveIdentity must reference the upstream dataset's ID.
Scenario 3 — No RLS → works fine confirms the architecture is correctly set up; it's purely a token + identity configuration issue
