Suggest an Idea

[Zareh_T]

It has been confirmed with Qlik that the OnDemand button only supports Windows NTLM authentication, that is when a user logs in to Qlik Sense via Windows, the OnDemand button then logs the user into NPrinting via Windows and the reports get generated immediately.

However, when a user is logged in to Qlik Sense via SAML authentication in Qlik Sense and NPrinting, The OnDemand button does not automatically authenticate the user into NPrinting and the report is not generated. This  is where the problem is and this feature / process does not exist in the OnDemand button functionality yet.

[ericschmid]

Thanks for this info - any thoughts on when this might be supported?

[millerhm]

This also means that it's useless for OEM partners - our customers are obviously not on our Windows domain, so we have no ability to offer on demand reporting without SAML authentication.

[Andrew_Kruger]

This remains open in the backlog but there is not resolution planned to this at the moment.  

[pabloviera]

This is a must, we (And I guess more organizations each year) moved from NTLM to Google SSO and can't use the OnDemand Reports.

[mmatena]

It would really be helpfull if this works, our organisation is moving towards a SAML authentication partner, so we cannot use the on-demand button anymore. 

[vegard_bakke]

@Zareh_T : Could you edit this suggestion to make it a bit more general?  It applies to any SAML integration. Not just Okta. It applies to Okta, Azure AD, Auth0, Google SSO, the lot. 🙂


We have an increasing number of customers moving to Azure AD.   And they are not happy when they realize that they suddenly lose their on-demand reports.  Qlik is advertising NPrinting as "supporting SAML 2.0".   First time I reported this, it was "fixed" by making the fine print a bit bigger. 

I'm not sure how many from the sales team around the world know that NPritning doesn't support SAML. At least all of NPrinting doesn't. (Which almost makes it worse.)

Qlik can either wait for this problem to grow too large. Because it sure will grow.  Or fix it sooner rather than later..

[vegard_bakke]

And just for the record: If you do fix this for SAML users.  Please include a way for the web ticket, JWT people to get correct section access when using on-demand as well.  Don't strictly limit yourself to SAML.

[vegard_bakke]

(Sorry. me again. : )

In the mean time. There might be a way around this. But it requires a bit of programming, and will not work for all usecases.

Copied from Qlik Parters Teams Chat:

here is a rough breakdown:

1) You need to make a web service, that can generate a JWT token *

2) You need a certificate that this module can use to sign the JWT token

3) You need to copy the public part of the certificate into NP JWT setup

4) You need a way to find the emailaddress (server-side) for the user (in my case the email is the Qlik userid, so I was lucky)

5) You need to modify the getLoginNtlm() function in the extension (like make a getLoginJwt()),

5a) This function needs to retrieve the JWT token from your web service (by passing on the session cookie, you can use Qlik Sense to verify who the user is)

5b) Having the JWT token, you request a (any?) API call from NPrinting server, and it will return a Nprinting session cookie

6) The Nprinting session cookie will follow any subsequent requests from the NP extension to NP server.

* NB! Never, ever, generate the JWT token based on information from the bowser only. HTTPS doesn't make the end-user a nice-guy. She can still send anything she like, just by pressing F12 in the browser. You can however, use the session cookie that is sent from the browser, and apply that to a server-to-server request to https://qlik.server.com/vproxy/qps/user.  Then the Qlik server will reply with the actual username that "owns" that session. 

So far, I have an unsolved problem: how to apply section access correctly.  There might be a way to programmatically (or manually) add users with the field "domain name".  Which apparently isn't a Windows NT domain name. Just a free text that gets passed to Qlik, so hopefully <userdirectory>\<userid> should work.  (Creds to Damien Vilaret if this works. 🙂 )

[hans_skjoethaug]

This is an important feature since our on-demand users are not in out local AD

[stiankarlsen]

This should have been fixed years ago.