Azure Web and Mobile built-in role
SignalR REST API Reader
Performs the documented read-only Azure SignalR REST existence checks: whether a group exists or a user exists in a group, whether a client connection exists, and whether a user exists. It does not enumerate groups, users, memberships, or connections. The role has no control-plane Actions and cannot write through REST APIs, start server connections, or generate negotiation credentials.
Role-definition permissions are imported from Microsoft Learn. Practical scope, use cases, prerequisites, best practices, security considerations, assignment guidance, and relationships have been reviewed against the official sources below.
Role definition ID: ddde6b66-c0df-4114-a159-3618637b3035
Control-plane actions (0)
None — this role grants no control-plane management actions.
Data-plane actions (3)
Microsoft.SignalRService/SignalR/group/readMicrosoft.SignalRService/SignalR/clientConnection/readMicrosoft.SignalRService/SignalR/user/read
Excluded actions (0)
None
Assignable scopes (1)
/
Practical scope
Assign directly on the Azure SignalR Service resource checked by the monitoring principal. A parent assignment is inherited by every SignalR resource below it and permits the same existence checks on each inherited instance.
Common use cases (2)
- Run a monitoring tool that checks whether a named client connection, user, or group currently exists.
- Check whether a named user exists in a named group without granting group mutation, broadcast, or negotiation authority.
Prerequisites (2)
- An Azure SignalR Service resource and a monitoring application or managed identity capable of obtaining a Microsoft Entra token must exist.
- The monitoring design must need only the documented existence checks; enumeration, server connections, negotiation, broadcasts, or group changes are not provided by this role.
Best practices (3)
- Assign to the monitoring identity on the individual SignalR resource and use Microsoft Entra authorization instead of access keys.
- Protect the names, identifiers, and existence-check results collected by the monitoring workflow.
- Elevate to REST API Owner only when a reviewed workflow must change data-plane state.
Security considerations (3)
- The role reveals whether named groups, users, client connections, and user-group relationships exist, but it does not return enumerations.
- It does not authorize server connections, client-token generation, or write-capable REST operations.
- A parent-scope assignment permits existence checks against all inherited SignalR resources.
Assignment guidance
Assign SignalR REST API Reader directly on the SignalR resource to the monitoring workload identity. Use REST API Owner only for approved management operations, App Server for Default-mode server connections, and Service Owner for the broader Serverless negotiation workflow.
Related roles (2)
- SignalR REST API Owner: Adds write-capable SignalR REST APIs and client-token generation.
- SignalR Service Owner: Provides all SignalR data-plane APIs, including REST, server-connection, and authentication operations.
Common questions
When should I assign the SignalR REST API Reader Azure role?
Assign SignalR REST API Reader when you need to: Run a monitoring tool that checks whether a named client connection, user, or group currently exists.; and Check whether a named user exists in a named group without granting group mutation, broadcast, or negotiation authority.. Practical scope: Assign directly on the Azure SignalR Service resource checked by the monitoring principal. A parent assignment is inherited by every SignalR resource below it and permits the same existence checks on each inherited instance.
What permissions does the SignalR REST API Reader Azure role grant?
The role definition grants 3 combined control-plane and data-plane actions. Representative operations include: Microsoft.SignalRService/SignalR/group/read; Microsoft.SignalRService/SignalR/clientConnection/read; and Microsoft.SignalRService/SignalR/user/read. Review the permission sections above for the complete definition and exclusions.
What are the security risks of the SignalR REST API Reader Azure role?
Key considerations when assigning SignalR REST API Reader: The role reveals whether named groups, users, client connections, and user-group relationships exist, but it does not return enumerations.; It does not authorize server connections, client-token generation, or write-capable REST operations.; and A parent-scope assignment permits existence checks against all inherited SignalR resources.. Follow the assignment guidance above and use the narrowest practical scope.
Editorial sources (7)
- Azure built-in roles for Web and Mobile - Azure RBAC | Microsoft Learn →
Supports: Description, Security considerations. Retrieved 2026-07-17.
- Understand Azure role definitions →
Supports: Description, Security considerations. Retrieved 2026-07-17.
- Steps to assign an Azure role →
Supports: Assignment guidance. Retrieved 2026-07-17.
- Understand scope for Azure RBAC →
Supports: Practical scope, Assignment guidance. Retrieved 2026-07-17.
- Best practices for Azure RBAC →
Supports: Best practices, Assignment guidance. Retrieved 2026-07-17.
- Microsoft Entra ID for Azure SignalR Service →
Supports: Description, Practical scope, Common use cases, Prerequisites, Best practices, Assignment guidance, Related roles. Retrieved 2026-07-17.
- Azure permissions for Web and Mobile - Microsoft.SignalRService →
Supports: Description, Common use cases, Prerequisites, Best practices, Security considerations, Assignment guidance. Retrieved 2026-07-17.