I have a website (ASP.NET MVC 4) that has users that need access to SQL Server Reporting Services. In the database for our website we have our user info and the user names are emails (Not sure if emails are allowed as login credentials for SSRS or not?). What I would like is for a user to be authenticated for the website and SQL Server Reporting services so that we may use the roles, which are also stored in our database, to control which reports users view.
I have read the documentation for implementing a SQL Server Reporting Services Extension but most of the examples implement a logon page for logging onto the SSRS ReportServer site. Whereas I would like my users to be authenticated to view/export reports on my website using a Reporting Services Service. At the very least I would like to authenticate when they log in and be able to redirect them to the Reporting Services Report Manager.
So my question is, is implementing an extension for authentication going to be necessary to view reports on my site?
I'm new to the realm of Reporting Services and am currently educating myself further on the subject, so please feel free to go into unnecessary detail.
Note: The website is being hosted on the same machine as Reporting Services, also SSRS is 2012 edition.
Related
I'm trying to wrap my head around the SSRS login. Here is my test setup.
SSRS 2016 installed on hostname: Testrs16
ReportServer Database installed on hostname: Server2
I'm launching ReportBuilder on Server2 and trying to connect and login to the report server (see screenshot). What login it typically used in this case? Thanks!
ssrs login
Authentication to your Report Server database is configured via the Report Server Configuration Manager. This will be the same for all users connecting to the Report Server.
Note: This is not the source of your data in your reports, but is where SSRS stores catalog information, user settings, and other internal components
Authentication Types for users connecting to the portal, web api, or soap endpoints are defined in your RSReportServer.config file as either RSWindowsNTLM (default), RSWindowsNegotiate, RSWindowsBasic, or Custom.
Once the user is authenticated (who are they?), then the authorization (what can they do) is defined in the folder management for catalog item security by assigning roles to users or groups.
The other authentication that is required for rendering a report is authenticating to your report's data source. This is defined in either the Report's Data Source or in a Shared Data Source. Either of these can be configured in the data source management page on the portal.
I am investigating a scenario/set up where we want to host SSRS 2016 Mobile reports for one of our clients and provide SSO using SAML.
As it is known, SSRS 2016 Mobile reports are consumed in Power BI app and as per the recent updates to Power BI app, it now allows OAuth to connect to Reporting Services (2016). The standard set up to do so can be found on Power BI site,
https://powerbi.microsoft.com/en-us/documentation/powerbi-mobile-oauth-ssrs/?mobileclient=ios
The above standard set up uses ADFS for user authentication when authenticating the user on Reporting Services (along with OAuth).
However, in our case, we would like to use SAML assertion over OAuth to provide authentication for Reporting Services as the Identity Provider is not in the same domain and is not something we have control over.
Does anyone have any experience/knowledge of if OAuth support for Reporting Services (SSRS 2016) will work with a SAML assertion from a separate Identity provider other than ADFS in the same domain as that of SSRS?
Is it correct to assume that in the above set up, we can simply replace the redirect URL to that of the third party Identity provider and it will simply show the login screen from the Identity provider to authenticate the user and pass the SAML token back to client to be used by SSRS?
There is a PoC available which uses SAML 2.0 Bearer Assertion Flow for OAuth 2.0 at the following location and I am not sure if this principle will work with SSRS 2016 Mobile reports in Power BI app?
http://blog.scottlogic.com/2015/11/19/oauth2-with-saml2.html
Look forward to any help/advice on this.
Happy to share more details if any of the above is not clear.
Cheers,
Hitesh
We are planning to deploy reporting service using Microsoft Reporting Server 2012. As I understand it, there will be three components;
Database (SQL Server)
SSRS (Reporting Server)
IIS (Web front end) - SharePoint (alternate Front end)
In setting up the Proof-of-Concept, the dev installed SSRS and SQL Server on same box (let's call it the DB server) and is redirecting client browser to a URL on DB Server from web front end.
Is it possible to architect the solution so that the web front end is the only destination for client browsers, SSRS lives on its own dedicated server separate from both the Web server and the DB Server?
How will authentication work in this scenario? We are using integrated authentication using Enterprise AD.
Configurations I have used in the past are these:
SQL Server on one server; SSRS native on another server. Users accessed reports via the SSRS Report Manager web UI that comes with SSRS.
SQL Server on one server; SSRS install in SharePoint Hosting mode on another server. Users accessed reports via SharePoint.
I am not 100% sure what you mean by “web front end is the only destination for client browsers”. If you mean that the end user only hits a web server, and not the database server to get reports, then either one of the above will work. If you have an existing intranet site that you want to host reports in, you can do so via web parts, if you are using MS technologies. You will still need SSRS setup somewhere so you can deploy reports, and the web part would read from it. Or, you can continue the redirect to either Report Manager or SharePoint if you go that route.
As far as authentication: the authentication between SSRS and SQL Server is usually done via an AD (Active Directory) user/service account that SSRS runs under, and also has access to the databases is uses on the SQL Server.
The authentication that allows users to browse and execute reports is usually done via AD as well. You can add all users to a central AD group and give that group Browser permissions on the SSRS server. This authentication would still apply if you use web parts to host reports outside of SSRS Report Manager.
The authentication that SSRS uses to pull the data that ends up showing in reports is usually SQL Server authentication, or whatever authentication that your data source supports where you can send a user name and password (which is stored within a shares data source on SSRS).
More Info
We have a analysis services olap cube (SSAS 2008) deployed at a test server (MS Serve 2008) in our domain, you can browse the olap cube via ssms without problem. No problems with olap cube itself so far. The user account is admin on the analysis services server.
We also have reporting services (SSRS 2008) installed at the same test server and have a datasource inside the reporting services report that fetch data from the analysis service olap cube. We have set up windows integrated authentication setting but the user trying to connect trough reporting services report to the olap cube get access denied.
An error has occurred during report processing. (rsProcessingAborted)
Query execution failed for dataset 'DsMillCd'. (rsErrorExecutingCommand)
Either the user, KORSNET\TFMAN, does not have access to the AnalysisServices database, or the database does not exist.
If i try out the same olap cube and report trough business intelligence studio local its working, so it must be some setting on the reporting services server.
Do reporting services connect to the analysis services as a another domain account?
I have searched and googled for a answer for about 6 hours now without luck, i'm getting a bit frustrated to get this working.
I think its only a configuration setting that i have missed, so all suggestions are welcome...
Are you logged on as KORSNET\TFMAN?
If the datasource set up for the report is set to use the credentials of the user then it will attempt to authenticate to the database as that user.
Does IE show the site as being part of the local intranet? If not go into security settings and add it.
Does that user actually have permissions to read the database?
It could be the "double-hop" problem where credentials can be carried and used once, but not again, however I think this is unlikely in this situation.
I have a problem about the credential in reporting service..
When I choose option windows authentication for a report in SQL Server Reporting Services, only the administrator can view the report. The other users can't view the report. But when I set credential stored securely in the report server and enter the username and password, all users can view the report but some data of the report is not showing.
For your information, I have created the user in SQL Server and I have set the role and user mapping.
What should i do?
Based off of what you are saying I would guess that you have not added the users windows credentials to the proper group on the reporting server. The admin would have access as by default that role is already given permission in the proper groups.
Here is an article from Microsoft that explains this process.
http://msdn.microsoft.com/en-us/library/aa274425%28SQL.80%29.aspx
This is a good article on setting up role based security.
http://odetocode.com/articles/215.aspx
If I understand your question properly, you want to use your end-users' windows credentials from end-to-end with your reports. You do not want to specify a specify set of windows or SQL credentials to connect to your data source, you want to use the end users' credentials instead.
In order to accomplish this, you will need to grant the end-users rights to access your reports in SSRS as well as granting them rights to run the needed SQL on the underlying database.
Finally, if your SSRS instance is not running on the same server as your database, you may run into security delegation issues. You can read more about this topic by visiting http://support.microsoft.com/default.aspx?scid=kb;en-us;810572