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!

[IAMDV]

Many thanks for the quick response. Here is what I get in event log:

Ticket Lookup: Ticket xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx was found.

Does this mean it's assigning a new ticket or just looking up? Because I've tried to search with the ticket ID and it's not available in the event (i.e. unique ticket each time) but it says "Ticket Lookup" in the event log message. This is confusing me.

Also, another question - We don't need a new ticket when we switch from AJAX to IE-Plugin or vice-versa, is this right?

Thanks again for your assistance.

Cheers,

DV

[Fredrik_Lautrup]

So there might be some confusion here. So I wrote a blog about just this confusion

What is a QlikView session?

So what I think you are referring to is the backend ticket that is used to create a connection between the server and the web server, rich client or plugin. These are created for every new session which in the server is defined as a user to a document. So in these cases is is you should get multiple tickets for a user.

The other scenario and the one I refer to above is about web ticketing which is a way to integrate with authentication solutions.

[IAMDV]

Okay. That makes sense now. So these multiple tickets shown in the even log are related to the connection between the Web Server/QVP and QVS (Basically, 2nd leg compared to 1st leg which is AJAX Client and Web Server).

Also, another question - We don't need a new ticket when we switch from AJAX to IE-Plugin or vice-verse, is this right?

Many thanks for clarification.

[Fredrik_Lautrup]

I'm unsure if a new ticket is needed when you move between AJAX and IE-Plugin.

If both go through the web server there should be no new ticket needed. But as I said I'm not sure.

[#6]

HI Fredrik,

I saw your post and its really helpful, I have a scenario.

1) we have customer portal which is built on Oracle framework manager, all the users access are maintaining in Oracle Identity manager(OID) which is nothing but LDAP.

2) I have qlikview 11 enterprise setup with Qlikview Web server configured , I can successfully import the users which are in OID by using LDAP directory in qlikview management console, however, I need to integrate those users so that user need not to pass his credentials to log in again in qlikview access point . currently we don't have any SSO software's in between.

Any suggestion how can I integrate LDAP and Qlikview access point with out SSO? if no how can I use SSO software  to enable Single sign on from customer portal to qlikview server.

your suggestions will help in my setup. Let me know if you need further details on the same pls.

if you have good documents so that I can refer, pls forward to suleman.imrankhan@gmail.com

Set up

OID(LDAP) on Solaris Box

Qlikview 11.2 Enterprise with Qlikview Webserver on Windows BOX with 64 GB of RAM

Regards

Imran Khan

[Fredrik_Lautrup]

The most frequent solution I see in these cases is the use of a reverse proxy to solve SSO. Most SSO solutions have this type of tool that can be deployed in front of QlikView and handle the authentication of the user before they are sent to QlikView.

In QlikView we have the concept of header authentication so that the reverse proxy once they have authenticated the user can forward the user information through the HTTP header.

I hope this guide you towards finding a solution that works in your specific case.

Regards

Fredrik

[raajeshn]

Hi Imran,

I have a similar situation - do you have any pointers on how you addressed this issue? Thanks for your support.

Thanks & Regards,

Raajesh N

[#9]

Hi,

I have a doubt ,In the authentication and authorization process the  qlikview services work is that because of  Section Access?   If not then is Section Access completely a second layer of security.

-Thanks

[Fredrik_Lautrup]

So there is one authentication process in QlikView which is done in the web server.

Then there are multiple access control systems

• Section access for data
• NTFS authorisation for those running with Windows Users
• DMS mode for those running non-Windows users

The different Access control systems will work together to add security to the data and resources (QVW's)

Regards

Fredrik

[Bill_Britt]

Hi,

To state you need to change the above to always. Then on the client you need to put the QV Webserver into trusted sites or enable the Intranet zone.

Bill