K2 4.7 when adding AAD service instance in the context of K2 service account you getting admin consent prompt despite it was already granted
kbt154191
PRODUCTK2 blackpearl
K2 smartforms
BASED ONK2 blackpearl 4.7
TAGSAuthorization
Security
This article was created in response to a support issue logged with K2. The content may include typographical errors and may be revised at any time without notice. This article is not considered official documentation for K2 software and is provided "as is" with no warranties.
LEGACY/ARCHIVED CONTENT
This article has been archived, and/or refers to legacy products, components or features. The content in this article is offered "as is" and will no longer be updated. Archived content is provided for reference purposes only. This content does not infer that the product, component or feature is supported, or that the product, component or feature will continue to function as described herein.
Issue
K2 4.7. OAuth token cached for K2 service account has expired causing inability to search against AAD label in different user pickers. You are trying to refresh/get new cached token for K2 service account by means of re-creating AAD Service Instance while running Tester Tool in the context of K2 service account but keep getting admin consent prompts despite admin consent for K2 app is already granted.Symptoms
In order to get AAD OAuth token for K2 service account you can use any credentials without special rights, but admin consent has to be granted for K2 app and this operation requires AAD Global Admin credentials to be typed in. Normally you don't need to type in these credentials on K2 server as consent can be granted by Global Admin via Azure Portal. In case of K2 4.7 when you are trying to get cached token for K2 service account you keep getting admin consent prompt even when it has been granted before.
You need to be aware about the following:
- Admin consent can be granted to K2 app on AAD side without typing in Admin Credentials on K2 server, this can be done in Azure Admin Portal
- It is best to have regular AAD user corresponding to K2 Service account to have its token associated with on-premise K2 Service account and its OAuth token will be used by K2 Service to authenticate against/connect to AAD
- K2 4.7 always adds &prompt=admin_consent parameter to URL whenever you attempt to register AAD instance in context of K2 Service Account, even when consent is granted
To workaround this problem, it is sufficient to remove this parameter from URL manually.
Why it works like that?
- We only prompt for Admin consent if service token is not cached, and this is true from 5.0 RTM onwards
- In 4.7 prompt=admin_consent is hard coded and will always happen
- The changes that allow us to only prompt for admin consent when the service token is not cached is part of an OAuth refactoring changes in K2 Five, which include AppOnly token and some required host server changes. It is not possible to retrofit/implement these changes in 4.7
Resolution
- Create separate regular AAD user without any special permissions to represent K2 service account in AAD
- Make sure that admin consent is already granted for K2 application in Azure Portal
- Re-register AAD service instance in the context of K2 service account using regular AAD user account created on step (1) and manually removing &prompt=admin_consent parameter from URL to avoid admin consent prompt
