Closed figuerres closed 6 years ago
We don't have plans to allow introducing additional middlewares in the owin pipeline or the start up of the owin pipeline. You will need to extend the existing interfaces in custom security in order to contact your identity provider and get the tokens.
It seems to me that someone needs to provide an example of the extension using OAuth/OpenIdConnect. The community has asked for this for years and still nothing. I am currently working on POC for using Power BI Report Server/SSRS and this is a must have and I have searching high and low on the internet and can't find a single example of a security extension that handles this.
@tstone84 what you need is here SSRS.Security for Practice Engine
you can take that code and modify it some, it works, I used it but i can't publish my version as they were done for my employer.
the main issues i had were setting up the cookie that the SSRS api's need after checking the token.
also the calls for the permissions did not pass the identity of the user so i had to get the email or role of the user in the checks for can this caller use this api method.
it was a bit messy but i got it to work.
Thanks for the response @figuerres ! What I'm looking to do is embed these reports within an Angular app, which is already using oidc jwt security. My only concern when I look at the interface and examples is supporting the logon method. It doesn't appear to have any sort of HTTP Context. Does this method get skipped if the auth cookie already exists?
@tstone84 you are doing in some form the same thing i am doing. we are both using OIDC / JWT to make access to the SSRS reports work with a JWT token.
ge the code that i refered to and spend a day or two with it. i say that as the way the internals of SSRS work are not trivial and a number of details have to be covered.
the long and the short of it is that the code can see a token and basically use the token to issue an SSRS cookie and that becomes a login session to the SSRS side of things.
the sample has a class that has code for that authors application logic that you will need to change to match your system.
also the SSRS internal logic uses a set of what start out as NTFS "Groups" which i treat as a kind of role claim in my logic. there is a way that you can add custom roles to SSRS but i found that to be a lot of hassle and no real value.
also some calls are made with a 'default' identity that you need to pass thru they are used to setup a call to the ssrs login api logic. if you do not pass them as ok then you get problems with many things.
also what i did was to install SSRS locally on my laptop and configure it with the dll that way you can debug the ssrs code from visual studio and see what happens to find the trick parts you need to handle. you have to attach to two processes one for the portal and the other for the old style xml api. the ssrs2017 portal hosts a new set of rest api calls along with the portal UI. thwo two work together but have different flows for some things related to the login user.
@figuerres Thank you so much for the information. You have been a tremendous help in my search for a solution to this problem!
@tstone84 as you work with the code if you have questions ask them.... want to make a clean copy of my code but just do not have the time to work and make a copy and explain the details. but as you hit snags if i know the way i handled it i can share what i found and how i handled it.
@figuerres This is an old thread, but we have just started working on something very similar, if not identical, to what you have done. Did you ever have time to make a clean copy of your code? Or are there any chances you can share more details?
Thanks! /Fredrik
@fredrikg
start with the code from https://github.com/PracticeEngine/SSRS.Security
it is very good as a base. setup a dev copy of ssrs on your laptop or desktop. use vs to debug by attach to process
there are multiple points where ssrs has to call back to the custom code. when you find them and handle them it can work. but its not a simple patch to make.
MS should really update to just let us say "JWT / OpenID" as the auth method and then point to the OpenID server to use....
the plumbing inside ssrs has parts that are years old and parts that are new and each works differently. that is why you need to step thru with the debugger and see what the heck is going on.
@figuerres Great thanks, I will give it a shot.
Just so I know: Did you ever get a redirect to the "logon form" to work, in case the user wasn't carrying a valid JWT-token? Or is an access denied page all I can expect?
@figuerres Thanks for this information, Right now i'm running into the same problem. Do you have any latest code available ? If a User is carrying the valid JWT token ,how to skip the "Logon Form" from SSRS ?
I tried to implement the security extension based of this thread. When I apply the extension, the Reports don't render/load properly in SSRS.
I have stripped down the security extension implementation to a bare minimum to rule out any of my custom code causing the issue.
See the issue I raised here for more details: https://learn.microsoft.com/en-us/answers/questions/1282498/ssrs-microsoft-reportingservices-rendering-dll-fai
I am looking at the sample code and and code from Identity server. in an Ide ntity Server 3 sample to switch from Web Forms to using identity server they use the .net / asp.net startup class to register using the STS server to obtain a token.
but SSRS is pre built so is there a way to get it to add my startup code ? normally i do this from a source project....
or will a later version of SSRS add a method to hook in other OWIN startup code ?