Qlik Sense: How to request an OIDC token manually and check if correct attributes are included (PowerShell)

[Damien_Villaret]

This article explains how to request a token manually from your Identity provider token endpoint and verify if the required attributes are included in the id_token.

Qlik Sense Enterprise for Windows reads the attributes from the id_token and is not using the /userinfo endpoint to fetch them.

Environments:

Qlik Sense Enterprise on Windows  May 2021 and higher
Qlik Cloud (For "ADFS" and "Azure" Identity provider types only)

First of all, for testing purposes, add the URL "https://test/login/callback" used in this script in your Identity Provider (IdP) allowed redirect URIs. The reason we are doing this is because we want to request the token manually to check its content and not have it getting automatically processed by Qlik Sense.

1. Run the below PowerShell script to get your authorization URL. Variables authorization_endpoint, client_id, and scope need to be updated to match your IdP, those information can be found from the /.well-known/openid-configuration endpoint.
   

   $authorization_endpoint = 'https://dc1.domain.local/adfs/oauth2/authorize'
   $client_id = '592a5672-a360-49da-93a4-20654f42d3c2'
   $redirect_uri = [System.Web.HTTPUtility]::UrlEncode("https://test/login/callback")
   #For ADFS, use 'openid%20allatclaims%20profile%20email' for the scope
   $scope = 'openid%20profile%20email'
   $code_challenge="7TsROgPKuP0hHoWWwEGqMsIOgzokT3xAz8kWoo7Ivp8"
   
   #Paste this URL in your browser to get back the authorization code
   $authorization_endpoint+'?response_type=code&client_id='+$client_id+'&redirect_uri='+$redirect_uri+'&state=xyzABC123&nonce=3O2bsVV99-kjikCWCxqzxOx007aXbKMUd0YXBwA3sUk&scope='+$scope+'&code_challenge_method=S256&code_challenge='+$code_challenge

2. Paste the URL output from the script in your browser and log in to your Identity provider, the URL should look like this:
   

   https://dc1.domain.local/adfs/oauth2/authorize?response_type=code&client_id=592a5672-a360-49da-93a4-20654f42d3c2&redirect_uri=https%3a%
   2f%2ftest%2flogin%2fcallback&state=xyzABC123
   &scope=openid%20allatclaims%20profile%20email​

   
   After the authentication is completed, you will be redirected to https://test/login/callback with an authorization code in the URL, copy the authorization code that we will use in the next step.
   
   Copy the value between code= and the next & sign. (The length of the authorization code may vary depending on the IdP)
   
   
   
   
3.  Request the token from the token_endpoint URL (also found from the /.well-known/openid-configuration endpoint)
   

   $client_id = '592a5672-a360-49da-93a4-20654f42d3c2'
   $redirect_uri = [System.Web.HTTPUtility]::UrlEncode("https://test/login/callback")
   $client_secret = 'Ssxx92jvm6RE_Plf1NnKgduZujE99nd0vWuujE_L'
   $token_endpoint = 'https://dc1.domain.local/adfs/oauth2/token'
   $code_verifier="_fqY.Xg5srawq24h9_A57tjY-ycqX0PzzIcM7VcwLZRou_Mvqn-_tCTz4ICWcXoCTO8NXlm3b9RfGOjSZEH68a_gWgaLByddN5y52M06~Z8XlO3XMgOJRWK0DefsxcmC"
   
   #Put your authorization code here
   $auth_code = 'mSzqI71WMUGuYcxSTciAcw.kZdiCG6J2QgNAPRcEZ9A51OMW6g.TMrNMhHPBiG3aNbh_4lbUakFzWoU_MFcDQZcL6_wBIaDd_1_DMWz9OZUSvRcE_zR115HwNXdZYUTjHB6mcnK3u5R2EDxsVKthwQwbP184ujVK1c8LmI-QOMb4jEGRTAm49nbtM8MfO4pTO1fICMSU7CLuhVb8KcCefjPOQ5W0JMKLl7XElvhJDLg5n6v1V2m8L2ZaCQVDy6oTiZygIr20j3TpQnpu2Zwk1KzbttOTGqeJgzCoyPJJJcRjnOrD1zPmBEENrz8fuZwdihRIPZufzhj0gEJ18-stWBz7polztBH7y_jKn-mK6WgIqlLSG2AlmcQa9kBANLmfbal7OUFtA'
   $pair = "$($client_id):$($client_secret)"
   $encodedCreds = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($pair))
   $basicAuthValue = "Basic $encodedCreds"
   
   $hdrs = @{}
   $hdrs.Add("Authorization",$basicAuthValue)
   $body = 'code='+$auth_code+'&grant_type=authorization_code&redirect_uri='+$redirect_uri+'&code_verifier='+$code_verifier
   
   $response = Invoke-WebRequest -Uri $token_endpoint -Method Post -Body $body -Headers $hdrs -ContentType 'application/x-www-form-urlencoded'
   echo $response.Content​

4. Copy the value in "id_token" from the request response, and decode the JWT token to see what it contains.
   
   For simplicity, you can use the debugger on https://jwt.io :
   
   
   
   You can confirm if the expected claims are included in the token payload or not.

[rockabs]

@Damien_Villaret  Any feedback on this? or @Sonja_Bauernfeind 

[Damien_Villaret]

Hi @rockabs 

Our documentation is still in the progress of updating the documentation.

You're getting an error because you haven't specified the attribute full name in the correct places, it needs to be in the email, name and sub fields in the virtual proxy settings.

Currently you have them in the "optional attributes" section, which is incorrect.

[bmenicucci]

Hello @Damien_Villaret , just a question: it looks I cannot add https://test/login/callback in Google OIDC settings, as it claims the following:

Invalid Redirect: must end with a public top-level domain (such as .com or .org).

Invalid Redirect: must use a domain that is a validtop private domain .

any idea? It would be really appreciated!

Thanks, Brunello

[Damien_Villaret]

Hi @bmenicucci 

Actually you can use any random URLs as long as the URL does NOT consume the OIDC request.

What about https://test.com/login/callback does that work ?

[bmenicucci]

Hi Damien,
actually it works, thanks a lot!!
However, after completing data in the script and copy/pasting the URL, I
get the following error:

Unable to process request due to missing initial state. This may happen if
> browser sessionStorage is inaccessible or accidentally cleared.


do you know what does this mean?
Thanks,
Brunello

[morenoju]

@rockabs, were you able to solve the Error 400 Bad Request issue?

[rockabs]

@morenoju Yes, I am able to fix that. Please check the above conversation and see, If you need any help just let me know.

Note: Please don't forget to tag my name when you respond or need my help.

[morenoju]

@rockabs , I'm getting the same 400 Bad Request error you were having. I've looked at the Audit_Proxy log in C:\ProgramData\Qlik\Sense\Log\Proxy\Trace and I see:

15161 20220404T175230.536+0000 WARN azure-qlik-demo Audit.Proxy.Proxy.SessionEstablishment.Authentication.OIDC.OidcAuthenticationHandler 131 378d8f51-28eb-48d6-822f-34bfd9135556 azure-qlik-demo\QlikServices Proxy.SessionEstablishment.Authentication.OIDC.OidcAttributeParserException: Exception of type 'Proxy.SessionEstablishment.Authentication.OIDC.OidcAttributeParserException' was thrown.↵↓ at Proxy.SessionEstablishment.Authentication.OIDC.OidcAttributeParser.ParseUserDirectory(JwtPayload jwtPayload, String subjectAttributeField, String realm)↵↓ at Proxy.SessionEstablishment.Authentication.OIDC.OidcAuthenticationHandler.<GetAuthenticatedUser>d__11.MoveNext() 0 862b90b5-0828-486a-8c3a-89434bc4caaf ::ffff:172.19.7.98 {keycloak} 043edfe1d2021b49bf6392980199db57289764d0

In your case, in the end, was it due to the mapping of attributes? What did you change in your configuration?

Thanks

[rockabs]

@morenoju

Make sure you have the correct statements in your diagnosis. If all goes well, would I recommend decrypting the testing parameters and see in the postman if it is as expected in OIDC?

I would also recommend enabling in one proxy only for review in the associated proxy. And also disable all attribute mapping where you just fill in the OIDC entry for validation.

And for my case. Yes, it is more related to the input given.

[morenoju]

Looks like I was missing setting the realm in the Qlik Sense Virtual Proxy. In QMC it says it's optional, but I didn't get this to work until I added it. Thanks.