13 Replies Latest reply: Jun 12, 2015 8:52 AM by Arun Gupta RSS

    http header for single sign on implementation

    Syed Shah

      Hi All,

       

      I have configured QV11 for single sign on (with IIS). I can successfully send the username in http header from fidler and it is working perfectly. However, I cannot make it work from my external website.

       

      Does anyone have a sample login page/loginsite code that can send the user info in http header to Qlikview accesspoint. I have tried the sample SSO code given with SSO for QV 10, but that does not work here.I am using QV11 Server and am using NTFS mode

       

      Your help will be very much appreciated

       

      Regards

      Arif

        • Re: http header for single sign on implementation
          Daniel Rozental

          I don't think it will work with NTFS mode, you definitely need DMS.

          • Re: http header for single sign on implementation
            Vlad Gutkovsky

            I'm experimented with this extensively and could never get it to work. Instead of header authentication, I always use ticket authentication. Since QV11, a cool new feature called "web ticketing" has been introduced that's much more powerful than header authentication. Search around the community for some examples.

             

            Good luck!

            Vlad

              • Re: http header for single sign on implementation
                Syed Shah

                Thanks for the suggestion. I have read somewhere that in QV11, web tickets only work with enterprise edition. Is that true? My customer is using some small business edition of license and I need to know if web tickets can work with this

                 

                Regards

                Arif

                  • Re: http header for single sign on implementation
                    Vlad Gutkovsky

                    Syed,

                     

                    While it's true that web tickets will only work with EE, the same restriction applies to header authentication--the reason being that both require DMS mode, and DMS mode is not available on SBE. If your client absolutely requires SSO, they may need to consider upgrading. I don't know of another way around it.

                     

                    Regards,

                    Vlad

                      • Re: http header for single sign on implementation
                        Syed Shah

                        Hi Vlad,

                         

                        Thanks a lot for the explanation. You are right. Our edition of license does not allow dms mode of authentication. I have just one more question though. When the QV server is still in NTFS mode and I send the request from fiddler and set the header to a user, it successfully logs in with the user without asking for user authentication. Can't I send the same kind of request from my website?

                         

                        Thanks and Regards

                        Arif

                          • Re: http header for single sign on implementation
                            Vlad Gutkovsky

                            Well that's interesting--just tried it on my own test server and you're right. I didn't think that was possible, but apparently header authentication doesn't strictly require DMS mode. However, is it actually hiding applications that the user is not authorized to see and, conversely, showing him all the applications that he should be able to see?

                             

                            When I tried it on my server, it is showing those documents where "Authenticated Users" have been given NTFS permissions. Once I remove "Authenticated Users" and add a specific user (DOMAIN\USER) then it no longer works even if I pass the QVUSER in DOMAIN\USER format. That tells me that it's not actually authenticating against the AD.

                             

                            Vlad

                              • Re: http header for single sign on implementation
                                Martijn ter Schegget

                                Hello Vlad, Arif,

                                 

                                You're right that in the case you describe QlikView doesn't authenticate against AD; according to page 73 of the Server Reference Manual it assumes the Single Sign-On system already authenticated the user, and 'the value in that header is what the QlikView server accepts as the authenticated identity of the user' (literal quote from p.73).

                                 

                                As far as I understood, in DMS mode QlikView will try to match the user's identity to the usernames authorized for this document in the DMS repository, and if that fails, try to lookup the members of authorized groups in DSC and match the user's identity with the names of members of authorized groups. This requires only a user name, and (if you have to do group lookups) access to the correct directory service through the DSC.

                                 

                                In NTFS mode, QlikView will try to impersonate the user and try to open the file; if Windows doesn't allow this, QlikView will also disallow access.

                                The problem in this case is: QlikView only has the user's username and no password or NTLM token, so QlikView cannot impersonate this user. The only option that is left, is opening the file through the QlikView service-account (or probably it is already opened and read into memory) - and QlikView only allows this if authorization on the file is set to 'All authenticated users'.

                                 

                                Hope this helps,

                                Martijn ter Schegget

                                The Implementation Group

                                 

                                PS: I hope the second part is not only conceptually but also technically correct; any of the 'big guns' care to agree or correct me?

                      • Re: http header for single sign on implementation

                        For the HttpHeader to work, you need some kind of ReverseProxy solution, which allows you to inject an Http Header. So your external website should go through an interim Reverse Proxy site which puts an Http Header before hitting your IIS.

                         

                        The problem is not with your IIS installation, as Fiddler has proved it right. Implementing a Reverse Proxy is a big thing, unless you already have one in place. Try googling for "Revere Proxy HttpHeader"

                        • Re: http header for single sign on implementation
                          Karthikeyan Subramaniam

                          Arif,

                           

                          Any luck for you ?. We are also facing the same issue (ie with fiddler it's working and not with normal website).

                           

                          Regards,

                          Karthi