Querying the Sense API about the current user

[vegard_bakke]

Hi all,

We are experimenting with a (Caddy) Reverse Proxy in front of Qlik Sense and other custom webservices. (Serving PDF documents, writeback capabilities to databases etc.)

Since both Qlik Sense and the custom webservice is behind the same reverse proxy, my webservice will receive the Qlik Sense session cookie.

But how can I validate that the session cookie is stil valid?

And more importantly, can I get the username, it's roles and groups, or even saml attributes?

That way we could achieve some access control, based on who was logging in.

Anyone with any tips on extracting user information based on the session cookie value?

Best regards,
Vegard

[Levi_Turner]

Since you have the session ID contained in the Session Cookie, you've got some options.

At the outset, the QPS API is a per virtual proxy API. This makes some sense due to the fact a given user can have a session on none, one, or many different virtual proxies. As a convention {/virtualproxy} will be used which means the prefix on the in-use virtual proxy. If it's the prefixless virtual proxy then this is not needed.

If you have the session cookie then you have the ID which means you can call GET /qps{/virtualproxy}/session. Example

GET /qps/session/f5a8a75d-a61e-4942-b12d-4b68d31bc26c

{
  "UserDirectory": "domain",
  "UserId": "userid",
  "Attributes": [
    {
      "UserPrincipalName": "userid@domain.com"
    }
  ],
  "SessionId": "f5a8a75d-a61e-4942-b12d-4b68d31bc26c"
}

If we had session attributes, they would be displayed like so:

{
  "UserDirectory": "DEMO",
  "UserId": "xyz",
  "Attributes": [
    {
      "extendedRole": "exampleRole"
    }
  ],
  "SessionId": "36ffb552-561c-484f-8ab8-a8a601f20a6b"
}

 Now that we have the userDirectory and userId values, we can do further queries to the QRS API to get the persistent attributes which would come from a User Directory Connector:

GET /qrs/user/full?filter=(userDirectory eq 'userDirectory' and userId eq 'userId')

Hope that helps

[vegard_bakke]

Hmm.. I get empty replies when querying the

GET /qps/session/{id}

I 'm using the default virtual proxy, so that should not be the trouble.
What access rights does the user requesting session info need?  (Can you access any persons session, if you know the ID?)

Anyway, I'm testing with user being RootAdmin, so I din't think that is the issue, either.

This was the session cookie for the user queried below. 

Can you spot my mistake in the curl statement below?

C:\> curl --cookie cookiefile --insecure "https://qlik.company.local/qrs/user/full?filter=UserDirectory+eq+'QLIK'+and+UserId+eq+'veba'&xrfkey=USE0YOUR0OWN0KEY" --header "x-qlik-xrfkey: USE0YOUR0OWN0KEY" --header "User-Agent: Windows"
[
	{
	  // ...znip...
	"customProperties":[],
	"userId":"veba",
	"userDirectory":"QLIK",
	"roles":["RootAdmin"],
	"attributes":[],
	"schemaPath":"User"}
]


C:\> curl --cookie cookiefile --insecure "https://qlik.company.local/qps/session/f8309fb7-82f2-48f3-b8f3-a453498bf83f?xrfkey=USE0YOUR0OWN0KEY" --header "x-qlik-xrfkey: USE0YOUR0OWN0KEY" --header "User-Agent: Windows"

C:\>

The user api is QRS and session api is QPS, right?

[Levi_Turner]

You'll want to go over 4243 using certificates: https://help.qlik.com/en-US/sense-developer/February2020/Subsystems/ProxyServiceAPI/Content/Sense_Pr... to communicate to the QPS. 

[vegard_bakke]

Is that a general advice for QPS only, or all APIs?

This is sidetracking: but I'm about  to integrate Qlik with an  Identity Management System, that will log on Qlik API, query registered users and delete users that no longer exists.

I was going to advice using either NTLM or SAML to get a session cookie, and use this for the QRS API. Rather than sharing and spreading the certificates and managing this with several other systems; as well as opening extra ports in the firewall.

Should I reconsider?
What are the arguments for certificate straight on the port versus going through the proxy with a session cookie?

[Levi_Turner]

There are always going to be trade-offs, yeah?

• Going over QPS
  • Pro: Use of 443 which is already likely allowed
  • Con: You have to deal with authentication programmatically, need to maintain the session state (using the cookie) for optimal results
• Going direct using certificates
  • Pro: Certificate trust ensures relatively easy authentication, authorization comes from a header value which is easy to manipulate in virtually all languages / frameworks
  • Cons: Requires the certificate to be shared with another system, requires an additional port to be opened (potentially)

I personally find the certificate route to be easiest to implement but if an additional port is required (i.e. if the code is running on a server in a different network segment) and that is a slow-going / laborious process, I understand why someone would go with the QPS route. If you can handle the authentication programmatically, then that con for the QPS approach is not too terribly difficult. Likewise, maintaining the session state can be easy for some developers. Harder for others. The concern over the certificate is a bit odd to me. Server side automation code requires a layer of trust since it can absolutely wreck any system, any app, etc. That's a natural potential consequence to automation; doing the wrong thing automatically.

There isn't a one-size fits all answer here.

[vegard_bakke]

Trade-offs are part of our trade, isn't it? 😉

Another benefit going through the Qlik Proxy is that you can control access for that system user, as well as revoke access.

As for exporting client specific certificates (https://localhost/qmc/certificates), I cannot find a way to revoke the certificate once exported.  Is that correct?  

I thought the sole purpose of being able to export certificates that are different from the local Qlik self-signed certificates would be that you could control each client's access.  The only other thread I've found is from 2016, and it is claiming that I need to recreate the QlikClient certificates (as in https://support.qlik.com/articles/000005402).

Do you know if that is still the case in 2020?

And do you know what the machine name is for? It's not being used to verify the sender, as far as I've tested. Is it mainly to separate the folders when exporting?

(Sorry, this is deviating quite a bit from the original post.)

[Levi_Turner]

> Do you know if that is still the case in 2020?

Yes. The generated cert comes from the same chain that the internal certificates come from. So there's a chain of trust there.

> And do you know what the machine name is for? It's not being used to verify the sender, as far as I've tested. Is it mainly to separate the folders when exporting?

Generally you would just pass the client certificate. The machine name value sets the issued to value on the server certificate. Practically, this is only really helpful in scenarios where you want to migrate Qlik Sense between servers (example: https://support.qlik.com/articles/000041283).