Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Accepted Solutions
I found out the solution by retro-engineering the Qlik cloud portal API calls :
The solution is to send an authenticated POST to /api/v1/identity-providers endpoint , for example with qlik-cli
qlik raw post /api/v1/identity-providers --body <BODY>
Where BODY is the following JSON payload :
{
"base64Encoded": <BEARER TOKEN FROM QLIK CLIENT MANAGED>,
"interactive": false,
"protocol": "qsefw-local-bearer-token",
"description" :"<a way to identify your Qlik client managed server>",
"provider": "qlik",
"tenantIds": [
"<qlik cloud tenant id>"
]
}
the <BEARER TOKEN FORM QLIK CLIENT MANAGED> is the bearer token you get when creating the deployment in QMC/Cloud distribution/deployment status in Qlik client managed. The value depends on the 'API endpoint' value so you need to go one step further if you really want to automate.
Hopefully and as name indicates it is a base64 encoding of another JSON
{
"issuerConfig": {
"issuer": "https://qlik.12345678-1234-1234-1234-123456789012"
},
"primary": false,
"realm": "custom",
"hostname": "<value of API endpoint field>",
"staticKeys": [
{
"kid": "qlik-12345678-1234-1234-1234-123456789012",
"pem": "-----BEGIN PUBLIC KEY-----xxxxxxxx(...)xxxxxxxx-----END PUBLIC KEY-----"
}
]
}
issuer, kid and PEM depends only on the Qlik client managed server and can be extracted from an existing bearer token created for another cloud distribution .
With these values , it is easy to craft the bearer token corresponding to the new cloud distribution and finalize the multi cloud identiy provider creation. 😁
What remains however is the capability to create the cloud distribution target in the Qlik client managed...
When applying reverse engineering method on QMC, we observe one POST request to https://<server>/api/dsc/graphql
with payload
mutation { SaveDeployment(deployment: { authenticationUrl: "" clientId: "" clientSecret: "" id: null name: "<" serviceUrl: "<API endpoint>" audience: "qlik.api" localBearerToken: true }) { authenticationUrl clientId id name serviceUrl audience localBearerToken } }
Analysis is still on-going to check if it is possible to call this API directly or if it requires specific authentication. Howver, one can already observe that response comes back with the 2 following headers
indicating there is some risks these APIs are not accessible or might change in future. So for the time being I will keep the manual method until this get promoted to QRS API.
of course, I searched the existing API
"https://your-tenant.us.qlikcloud.com/api/v1/identity-providers"or Qlik-cli
qlik identity-provider create
but it sems to cover only SAML , OIDC or JWTAUTH whereas the admin portal has 4 options
I found out the solution by retro-engineering the Qlik cloud portal API calls :
The solution is to send an authenticated POST to /api/v1/identity-providers endpoint , for example with qlik-cli
qlik raw post /api/v1/identity-providers --body <BODY>
Where BODY is the following JSON payload :
{
"base64Encoded": <BEARER TOKEN FROM QLIK CLIENT MANAGED>,
"interactive": false,
"protocol": "qsefw-local-bearer-token",
"description" :"<a way to identify your Qlik client managed server>",
"provider": "qlik",
"tenantIds": [
"<qlik cloud tenant id>"
]
}
the <BEARER TOKEN FORM QLIK CLIENT MANAGED> is the bearer token you get when creating the deployment in QMC/Cloud distribution/deployment status in Qlik client managed. The value depends on the 'API endpoint' value so you need to go one step further if you really want to automate.
Hopefully and as name indicates it is a base64 encoding of another JSON
{
"issuerConfig": {
"issuer": "https://qlik.12345678-1234-1234-1234-123456789012"
},
"primary": false,
"realm": "custom",
"hostname": "<value of API endpoint field>",
"staticKeys": [
{
"kid": "qlik-12345678-1234-1234-1234-123456789012",
"pem": "-----BEGIN PUBLIC KEY-----xxxxxxxx(...)xxxxxxxx-----END PUBLIC KEY-----"
}
]
}
issuer, kid and PEM depends only on the Qlik client managed server and can be extracted from an existing bearer token created for another cloud distribution .
With these values , it is easy to craft the bearer token corresponding to the new cloud distribution and finalize the multi cloud identiy provider creation. 😁
What remains however is the capability to create the cloud distribution target in the Qlik client managed...
When applying reverse engineering method on QMC, we observe one POST request to https://<server>/api/dsc/graphql
with payload
mutation { SaveDeployment(deployment: { authenticationUrl: "" clientId: "" clientSecret: "" id: null name: "<" serviceUrl: "<API endpoint>" audience: "qlik.api" localBearerToken: true }) { authenticationUrl clientId id name serviceUrl audience localBearerToken } }
Analysis is still on-going to check if it is possible to call this API directly or if it requires specific authentication. Howver, one can already observe that response comes back with the 2 following headers
indicating there is some risks these APIs are not accessible or might change in future. So for the time being I will keep the manual method until this get promoted to QRS API.
