Well you have to use your own custom written authentication DLL with SSRS unless you are running the whole thing on a Windows domain then you need to be able to pass authentication cookies and the like between the SSRS web server and your, in my case, web application.
SSRS creates a SQL Server database to stored it's stuff and there are certificates protecting that. So you need to have you SSRS installation talk to a database on a different system or at least on full on VM on Azure as opposed to some Azure SQL database set-up
Even presuming I'm wrong and you can in fact connect this all up it all adds up to one big house of cards waiting to fall apart. If I had a time machine I would travel back and prevent us from ever going near SSRS with a barge pole. Aside from the complexity and difficulties getting custom security configured (poor documentation, no tools to aid config), Microsoft are clearly abandoning it as they are doing there best to destroy it, such as it was. In SSRS 2016 and higher they:
- changed the security interfaces (re-write of our custom security required)
- only allow 1 install per server, whereas with 2014 and below it was the same as SQL Server instances. Given we install an SSRS instance per customer that means we screwed over again and will need to refactor our entire reporting integration in order to take account of this before we can switch to SQL 2016 or higher
MS is clearly more interested in PowerBI. Not that I'm in any way bitter of course, 😛