5 Replies Latest reply: Mar 21, 2015 2:43 PM by Jeffrey Goldberg RSS

    Implementing SSO authentication with Http Headers

      Hi,

       

      I have been attempting but failing to build Single Sign On (SSO) authentication with Http Header for Qlik SENSE.

       

      I installed Qlik Sense Server. I built a User Directory Connector, named CMI, it signs successful on Sync. UserID's are pulled from a SQL DB, although non show in Tokens and Licenses tab.

      All services (QPS, QRS, etc.) are on the same server. So no certificate export is required for that sake.

       

      I built a new virtual Proxy with following properties:
      Prefix (A_).
      Session cookie Header Name (although not sure what this is used for).

      Authentication:

      Header Authentication mode: Dynamic User Directory

      Header Authentication Header Name: CMI_Header
      Header Authentication Static UD: [blank]

      Header Authentication Dynamic UD: $ud\\$id
      Anonymous accses mode: No anonymous user

      Windows authentication pattern Windows (no other option).

      Integration: [all blank].

       

      I exported the certificates (server, client, root) and doubleclicked them in a remote pc on the intranet.
      To test: From a remote pc, I try to send Header requests from a Google Chrome browser extension, named: "Advanced Rest Client". Header configuration is:

      CMI_Header=CMI\Me
      where "Me" is a user in the user directory.

      When I try a Get/Head http request from that remote pc it asks me for win credentials and when I supply Qlik admin credentials (which is a AC windows admin too) it logs in fine to Qlik. And it doesn't matter whether I put any/correct header or not.

      But when I choose Post/Put/Delete, etc. http requests it doesn't work, saying "0 No Response", whether or not the header parameters look fine.
      Any reason why? What am I missing?

       

      What I need is it to work for my User Directory users with SOO (Header) authentication.

       

      Thanks very much in advance,

      Amir.

        • Re: Implementing SSO authentication with Http Headers
          Jeffrey Goldberg

          Amir,

          the Session Cookie Header Name is very important in the virtual proxy as it identifies to Qlik Sense that the browser session accessing content is valid and authorized.  Session Cookie Headers need to be unique for each virtual proxy so make sure your Session Cookie Header Name is something like X-Qlik-Session-A_ if A_ is really the prefix for your virtual proxy.

           

          Now, as for what is happening with your attempt to get authorized via header injection.  One thing that does not appear in the information you have provided is a cross-site scripting key (aka xrfkey)  This key is necessary as a parameter in the url and a header value labeled X-Qlik-xrfkey if you are trying to connect to the rest apis.  Without this parameter and value your request will be rejected.  If you are trying to connect to the hub, it does not appear to be necessary, but you may want to test both scenarios.

           

          When I'm testing header authorization for apis and general connectivity, I use the PostMan chrome extension.

           

          Here is what my request looks like.  It is a get request.

          The response is the HTML and if you look at the cookies, the session cookie is provided.

            • Re: Implementing SSO authentication with Http Headers

              Thank you very much Jeffrey. Yes I assigned a cookie name in my new dynamic header virtual proxy. Is that's enough or should I put anything in my reverse-proxy (or chrome extension) that (re)pushes this cookie back.

               

              For xrfkey: Does Qlik Sense (QPS/QRS) need to recognize this key? Or just assign a header (say named X-Qlik-xrfkey) and value (say abcdefg123456789) and a URL get parameter with the same name and value: Say https://QPSserver:4243/_A?X-Qlik-xrfkey=abcdefg123456789
              Where 4243 is the default Authentication port for QPS proxy.
              I tried this above link https://QPSserver:4243/_A?X-Qlik-xrfkey=abcdefg123456789
              I also tried it while alternating: Get vs Post requests, 4243, 4244. Still I receive 404 (wrong request).

              Before that: Interestingly the cookie name in the 404 http response is the default virtual proxy (<>default, which is win authentication). So it seems that it isn't using new dynamic header virtual proxy "_A".

              Interestingly also, after I exported the (server-root-client) certificates from QRS into my reverse-proxy server, when I first tried https://QPSserver:4243 it did ask me to pick a certificate (from a poped-up list), then when I picked the Qlik certificate (in one user I picked reverseProxy certificate, in another user I picked QlikClient certificate) then it gave me the 404 response and default-virtual-proxy cookie X-Qlik-Session, and it never asked me again for a certificate in following attempts. So it seems as if it has the Authentication port 4243 functional but didn't manage to find the good virtual proxy or the good certificate.
              I seem to have been missing a configuration. Do I have to populate the virtual-proxy "integration" section with any values?

              Thanks again for all help,
              Amir.

                • Re: Implementing SSO authentication with Http Headers
                  Jeffrey Goldberg

                  Amir, refer to the linked document http://community.qlik.com/docs/DOC-8135.  From what you typed above the parameter in the url is supposed to be xrfkey, not X-Qlik-xrfkey.  X-Qlik-xrkey is a header you add to the request.  Yes the values for both the parameter and the header are the same.

                   

                  If you are trying to connect to QPS or QRS then the xrfkey is a requirement.  The Session Cookie value is returned upon successful authorization.

                   

                  Here is a doc I created for properly configuring a virtual proxy and testing with postman and fiddler.  This document is relevant for Qlik Sense 1.1.

                   

                  As far as the certificate requests that pop up it's a result of increased security measures by modern browsers to prompt you to use a client cert when connecting to web sites through https.  In IIS you can configure so that client certs are ignored in ssl connections.

                   

                  For my test environment, I exported the certs from the Qlik Sense server and imported them into my local.  I placed the root cert into the localmachine\trusted root cert authority location and the QlikClient into the localmachine\personal location.

                   

                  jg

              • Re: Implementing SSO authentication with Http Headers

                Thanks very much! It definitely advanced my attempt. Now I can successfully http-request https://QPSserver/_A?X-Qlik-xrfkey=abcdefg123456789 (prefix now works in URL). I can also find the header virtual-proxy cookie: X-Qlik-Session_A, in my http response. However it works whether I put any "right" authentication header (CMI_Header: CMI\Me) or not. So it doesn't seem to be authenticating the UD\\UI.
                Also before applying your settings, when I used to access https://QPSserver/_A from chorme-URL bar, it didn't recognize the header-virtual-proxy prefix, rather redirects me to:

                But now a chrome-popup window is asking me for username/password, as if it failed on authenticating on Header params (CMI_Header: CMI\Me), and now looking for windows (default virtual-proxy) one.
                Kind reminder: X-Qlik-xrfKey:abcdefg123456789 is added as header, and ?Xrfkey=abcdefg123456789 is added to URL.
                Am I missing anything on configuring the linkage between the User directory (CMI_Header) and the header-virtual-proxy? Again "CMI_header" is the Header-Auth header name in my Header-Auth virtual proxy. "CMI" and "Me" are a sync'ed user-directory name and a userId in it respectively.
                The users of CMI aren't showing anywhere (not in Users tab, neither in Lisenses&tokens>User access allocation section).

                 

                Thanks a lot again.
                Amir.