Secure reports (Azure SQL Reporting)
Updated: May 9, 2014
|SQL Reporting will discontinue service on October 31, 2014. See this FAQ for details. For reporting on Microsoft Azure, visit Virtual Machines on WindowsAzure.com.|
All users who access reports on SQL Reporting via URL access must have a report login.
Creating a login, or report user, consists of entering a user name and password, and choosing an initial role for that user. Valid roles include Browser, Publisher, and Content Manager. My Reports and Report Builder roles appear as available roles in the management portal, but they do not apply to SQL Reporting, having the same functional level as the Publisher role.
Each report user must be registered manually. There is currently no programmatic approach for registering users. For more information about creating a report user login, see Manage Users (Azure SQL Reporting)
Permissions are inherited from the parent object. The initial role that you choose for the report user determines the permissions at the root node of the report folder hierarchy. You cannot change the initial role once the report user is created in the management portal, so if you make a mistake, you will need to recreate the user or modify the role assignment programmatically.
For any item in the hierarchy, including items directly under the root node, you can override the role at the item level. For example, suppose Sue Smith is assigned to the Content Manager role at the root node. Changing her role assignment to the Browser role on specific items effectively reduces her permissions for those items.
A report login is different from the database login. SQL Database and SQL Reporting do not share user information or a security framework.
Depending on how you configure data access in your reports, users might have to provide credentials twice. Specifically, if you configured a report to use prompted credentials to retrieve data, the user must first sign in to the report, and then provide a user name and password to retrieve the data. As a convenience to report users, we recommend using stored credentials with a shared data source. However, if data access is dependent on user identity, you will have to configure the report to use prompted credentials, as there is no pass-through identity delegation in SQL Reporting.