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
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.
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
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"
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.
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?
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.
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?