Authentication and Authorization

[Fredrik_Lautrup]

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:

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.

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!

[rajeshvaswani77]

Hi Fredrik, thanks for the blog. Has been helpful.

[rwunderlich]

Hi Fredrik,

Consider a QV11 WebTicket user. If the user clicks the Ajax "Close" button on a document, can they reconnect using the same ticket/cookie? Or do they have to obtain a new ticket for the restore.

-Rob

[Fredrik_Lautrup]

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?

[MK_QSL]

Hi Fredrik, Thanks for sharing this useful information.

[#6]

Hi Fedrik,

Thanks for Info, We have purchased the QW SBE server license, but we don't have AD in our organization.

I have requested our partner to implement QW SBE Server with LDAP. Partner did some R & D but failed to integrate the QW SBE with LDAP for User Authentication and authorization. Request you to kindly provide some solution on implementing with QW SBE with LDAP. I hope you will surely have solution on the implementing QW with LDAP.

Regards,

Akiv Kandlekar.

[Anonymous]

SBE does not support "DMS"-Mode (you can see this in your LEF file).

As SBE only works with file based NTFS Authentication you can only use:

- Active Directory

- local Windows users&groups

For NON-Windows Authentication (== LDAP) you need an QlikView Enterprise Server.

[#8]

Dear RVA,

Thanks for your quick response.

Do you mean to say that i can install and implement QW SBE with the help of local users & Groups on the same local server as well, since we don't have  AD. Is it possible?

[Anonymous]

HI!

Yes, local user should work.

-Create a local administrator that run the QlikView Services.

-Create a local user for each of your QlikView users.

Drawback:

You don't get a single sign on for your endusers (they always have to type their local user+ password to enter QlikView Accesspoint).

[#10]

Thanks for this very clear explanation. It is a topic that seems obvious when you understand it but often causes confusion so I will keep a note of your page to refer others to it.

[#11]

Thanks RVA.

I was initially thinking about the same, but here people are creating unnecessary confusion that Without AD, QW SBE Server cannot authenticate or authorize.

Now, i will try the option suggested by you i.e. local users and revert. I hope it works for sure ...!!

Regards,

Akiv Kandlekar