none
Authenticating via RESTful API RRS feed

  • Question

  • To whomever might assist:

    I am working on a project - a website built with Java and React - that requires SSRS integration.

    What I Want

    To render reports from SSRS - obtained via REST API or in an iframe - to logged-in website users without prompting said users for SSRS credentials.

    Why I Want This

    I have already established a working method for authenticating (NTLM) against the report server via Java + SSRS Web Services. I can render reports obtained via WS SOAP, but

    • Getting this to work was an absolute horror
    • NTLM is antiquated
    • Rendering reports in this manner causes me to lose the always-handy ReportViewer

    Delivering the reports via iframe would prospectively cure these ailments, but the question then becomes how to avoid prompting the site user for SSRS credentials?

    Obtaining the reports by way of the new REST API sounds great and would nix issues 1 and 2 above, but how does one authenticate requests without first being signed into the report server?

    Creating a custom authentication extension isn't something I want to do. For one, this is a Java environment which automatically adds layers of complication. And for another, it is my understanding that the report server, if employing a custom authenticator, will not handle standard Windows auth. That's no good for me.

    So, any ideas? Am I just missing something? Maybe it's as simple as the REST API session endpoints requiring the report server to be set with a specific authentication mode?

    Any help with this issue would be greatly appreciated. Thank you.

    - Rob

    Monday, January 8, 2018 9:44 PM

All replies

  • Hi,

    I think it it necessary to configure the custom authentication in order to make the website users (external users?) have access to the report. Configure Custom or Forms Authentication on the Report Server

    And to embed the report into the application, there are the Report Server Web service, also known as the Reporting Services SOAP API, the ReportViewer controls for Microsoft Visual Studio, and URL access. See Integrating Reporting Services into Applications

    BR,

    Henry 


    Tuesday, January 9, 2018 2:14 AM
  • Henry:

    Thanks for the reply.

    I think it it necessary to configure the custom authentication in order to make the website users (external users?) have access to the report.

    My current solution, mentioned in my original post, utilizes SSRS web services to access the report server and render reports for the end user. Basically, a user logs in to the website with their website credentials and then, behind the scenes, the application logs into the report server via web service using NTLM authentication. The user can then make ajax requests to the application, which hits the report server via web service and responds with whatever was fetched.

    I outlined the issues with this technique as threefold: difficult to set up and maintain, causes the loss of the ReportViewer component, and NTLM isn't the best. Additionally, the SOAP web services are deprecated in favor of the new RESTful API.

    Report Server Web service, also known as the Reporting Services SOAP API, the ReportViewer controls for Microsoft Visual Studio, and URL access.
    • The SOAP web services are what I'm currently using and would like to get away from.
    • The ReportViewer control is not applicable to a Java application. It is also mnot available when obtaining reports via web service. This is why I am trying to integrate SSRS via iframe, if possible.
    • URL Access - I'm pretty sure - would still require the user to enter report server credentials via client-side prompt. The main purpose to my writing here is to suss out a method by which to avoid this completely.

    Thanks again for the reply.

    - Rob

    Tuesday, January 9, 2018 4:03 PM
  • Hi,

    Thank you for your reply. You could find Restful API for ssrs from this site. But it seems no authentication related ones currently. 

    BR,

    Henry 

    Wednesday, January 17, 2018 2:57 AM