azure-lighthouse-external-maps-to-role

id: azure-lighthouse-external-maps-to-role
emits: ExternalIdentityMapsTo
applies_to:
- azure
match_record:
  resource_type: Microsoft.ManagedServices/registrationDefinitions
  field: properties.authorizations
where:
- each item in properties.authorizations[] where roleDefinitionId != '8e3af657-a8ff-443c-a75c-2fe8c4bcb635'
emit:
  source_type: ExternalIdentity
  target_type: Role
  source: <ExternalPrincipal node (principalId, same as TrustsExternalIdentity target)>
  target: "<Role node (roleDefinitionId resolved \u2014 built-in or custom role in customer subscription)>"
  api_source: GET /subscriptions/{subId}/providers/Microsoft.Authorization/roleDefinitions/{roleDefinitionId}
  evidence_field: properties.authorizations[].roleDefinitionId
  note: Resolve roleDefinitionId to a role node in the customer subscription. For built-in roles (GUID
    matching known built-ins), use the canonical built-in Role node. For custom roles, resolve via the
    roleDefinitions API. The (TrustsExternalIdentity, ExternalIdentityMapsTo) pair forms the normalized
    trust representation that federation-chains.yaml federation-maps-to-identity consumes to derive CanFederateAs(?ext
    -> ?role). For Lighthouse this is ARM-RBAC-based cross-tenant access (not OIDC/SAML), so the CanFederateAs
    semantics represent a delegated-role assumption rather than token federation; the path-finding consequence
    is identical.
  narrative: Managed-tenant principal {external_principal.name} is mapped to delegated role {role.name}
    ({roleDefinitionId}) in customer subscription {customer_sub.name}.