Skip to main content
Fredrik_Lautrup
Employee
Employee

Authentication and Authorization are two important concepts in securing any application.  Let’s start with some simple definitions.  Authentication makes sure that the person accessing the system is the person he says he is.  Authorization only lets you access information and complete actions that you are allowed to, based on your identity.

In QlikView, these are two distinct activities performed independent of each other.  This often creates some confusion and configuration errors, so let me explain how it works.  When a user gets access to QlikView it is always done in these four steps:

Flow.png

One of the most common misunderstandings around this is what services are part of what step in the process.

The first two steps covering authentication are handled by the web layer (i.e. QVWS or IIS).  The third step is achieved by the web layer transferring the identity to the QlikView Server using the QVP protocol.  The fourth step is authorization and is handled by the QlikView Server using groups resolved by the Directory Service Connector.

There are some big benefits to this approach:

  1. QlikView does not have to store passwords; these are stored by an identity provider such as LDAP or AD.
  2. Normal procedures for user management can be applied, which enables that adherence to security policies are maintained.
  3. It is possible to customize authentication without affecting authorization, which gives us the option to use external identify providers such as Google and Salesforce.
  4. All Authorization is done in the backend, making it easier to protect.

The role of the Directory Service Connector in the flow is somewhat blurred by the fact that almost all QlikView components use it. The web layer, QlikView Server, QlikView Management Service, and the QlikView Publisher all use the Directory Service Connector for different things.

Most QlikView components use the Directory Service Connector for authorization or to get information about users except if custom users are used.  If you use custom users, these  get authenticated towards the Directory Service Connector, which in this special case stores identity and passwords for the users.

Achitecture.png

Remember, as a rule of thumb: the front end components handle authentication and the backend components handle authorization.  I hope this help gives you a clearer picture of how QlikView handles authentication and authorization and which components are used in which part of the flow.

Have further questions you’d like me to answer?  Leave me a comment!

38 Comments
Not applicable

Dear RVA,

I am trying to do the R&D with QW SBE V11 SR2 with local users on Windows server 2003 R2 Std.

Need your help if you can suggest the installation guide as well as deploying on the Named and DOC CAL licenses as we are using the local users and groups of the Qlikview server. It will be of great help.

Thanks,

Akiv Kandlekar

0 Likes
3,173 Views
Fredrik_Lautrup
Employee
Employee

A think the best solution for you as it is a implementation specific question is to contact support and let them guide you.

Regards

Fredrik

0 Likes
3,173 Views
Not applicable

Hey guys, 

I am given a task to calculate the frequency of calls across a territory. If the rep called a physician regarding the sale of the product 5 times, then frequency is 5 and HCP count is 1....I generated frequencies from 1 to 124 in my pivot table using a calculated dimension which is working fine. But my concern is :

My manager wants frequencies till 19 in order from 1..2..3..4...5..6.....19...

And from the frequency 21-124 as 20+.

I would be grateful if someone helps me with this.....Eager for the reply....

0 Likes
3,193 Views
thebestbrew
Contributor
Contributor

Hi Fredrik,

Good article, thanks. I have a scenario not specifically addressed in the documentation. We are implementing the Small Business Edition at this point.

We have a multi-domain environment without trusts and users will be in different domains - probably accessing different QV applications. We will want to use one of those domains for authenticating it's users (the majority of users) and that domain's AD is located on the same network as the QVS.

Reading the server guide and your article can you confirm if we can run 2 web sites, one using IWA and the other using custom users for authentication - as long as we can separate the documents? Are there any specific problems which we'll need to address for this configuration?

Thanks in advance

Frank

0 Likes
3,193 Views
Fredrik_Lautrup
Employee
Employee

So technically you can support multiple ways of authentication using multiple web servers. The limitation is that we can only support one authentication method per web server.

I'm not an expert in our licenses so there might be restrictions in the Small Business Edition that limit this but technically it is possible.

//Fredrik

0 Likes
3,193 Views
thebestbrew
Contributor
Contributor

Thanks for your prompt response, Fredrik.

I'll post separately on the license issue.

Frank

0 Likes
3,193 Views
Brett_Bleess
Former Employee
Former Employee

Hey Frank,

I just wanted to answer you here, Customer Users will not work with Small Business Edition license due to the need to run QVServer in DMS Security Mode when using the Custom Directory DSP, and this is not allowed with Small Business Edition license. 

What you could do though is use the Local Directory DSP on the server to create accounts for the folks you were considering creating in Custom Directory and the license should be able to handle things, as Local and Active Directory are both supported in the Small Business Edition license.  Hope this helps.

Regards,

Brett

0 Likes
3,193 Views
thebestbrew
Contributor
Contributor

Thanks for the tip Brett. Appreciated.

Frank

0 Likes
3,193 Views
IAMDV
Luminary Alumni
Luminary Alumni

Hi Fredrik,

Fredrik Lautrup wrote:

The ticket is only valid for a short period of time and can only be used once. So the same ticket can not be used to re-authenticate.

The session could be used if it is still valid. If you just click close the session is still valid and you will not have to re-authenticate using a ticket.

If you close the browser or the session time out then you would need to re-authenticate using a new ticket.

I hope this answers your question?

Why do I see different tickets for the same user and same session in the Event Log? I'm not closing the session neither the browser. What is the time period for a single ticket? Can this be controlled by the Admin?

Thanks in advance.

Cheers,

DV

0 Likes
3,196 Views
Fredrik_Lautrup
Employee
Employee

I think that the timeout for a ticket is 1 minute and can not configurable. I'm unsure while you see more than one ticket. A ticket is only needed when you need to re-authenticate which should only happen if you don't have a session or the session is invalid.

Do you have more than one webserver that you load balance between? A session is only valid within a webserver so if you en up on another you will need to re-authenticate.

0 Likes
3,196 Views