This article applies only to K2 Cloud instances that are upgraded from K2 Appit. This does not apply to newly-provisioned K2 Cloud instances or K2 Five.
In K2 Cloud, the K2 for Office 365 app requires less Azure Active Directory (AAD) permissions compared to the older Appit version. Namely, the ability to write to your AAD instance is removed and only the ability to read AAD properties is retained. These permissions are now requested by the Azure Active Directory Management for K2 app, which you can manually configure for the AAD service instance if you want to use the AAD user and group wizards in a workflow.
If you were upgraded from K2 Appit, there is nothing you need to do. The original K2 for Office 365 app is used since that was previously granted consent. However, if you want to use the reduced permission scope for the new K2 for Office 365 app, then you must manually re-consent to the K2 for Office 365 app, which still requires you to use an AAD Tenant Admin account.
If you are upgrading from K2 blackpearl to K2 Five, and you have workflows in SharePoint Online that write to AAD, as part of the post-installation tasks you should re-run the SharePoint Registration Wizard. This forces K2 to use the reduced scope of the K2 for Office 365 app, after which your AAD SmartObjects are no longer be able to write to AAD. You can also follow the steps in How to Reconsent App Permissions section below to do it manually. See Azure Active Directory Management for the configuration steps to configure K2 to have AAD write permissions.
The only difference between the old app and the new app is the removal of the AAD write permissions. Full control permissions are still required for SharePoint.
How to Reconsent App Permissions
To reconsent the K2 for Office 365 app permissions, enter the following URL into a browser:
https://trust.k2.com/<domain or tenant id>/authorize/oauth/2/request?client_id=ca5cc53d-936b-4e82-ba6c-6b013c961933&response_type=code&redirect_uri=https://<FQDN>/identity/token/oauth/2/authorized&resource=https://graph.windows.net&prompt=admin_consent
There are two elements in the URL that you need to set based on your environment:
- For the domain or tenant id, you can find this value in the current K2 for Office 365 OAuth resource in K2 Management:
- Open K2 Management
- Browse to Authentication > OAuth > Resources
- Select the “MSOA” resource
- In the Resource Parameters list, find and copy the Token Value of the entity_id parameter.
- Place the value in the <domain or tenantid> placeholder of the example URL
- For the FQDN, find and copy the base URL (without the protocol) of the Token Value of the redirect_uri parameter.
- Within the Resource Parameters list, find and copy the domain portion of the Token Value of the redirect_uri parameter.
In this example, the value you copy is k2.denallix.com.
- Place the value in the <FQDN> portion of the URL
In this example the final URL looks like:
Pasting this URL into a browser allows you to log in as the AAD Tenant Admin to start the consent cycle:
Once logged in, you are prompted to consent to the permission request of the new K2 for Office 365 app, which includes the following permissions:
The first two permissions are related to AAD. The remaining permissions, such as Read and write user profiles, are related to SharePoint Online and not AAD. These permissions are required for K2 integration with AAD and SharePoint Online.
Click Accept and you are redirected to the Authorization Successful page.
From this point forward, the new K2 for Office 365 app permissions are used by K2, meaning that the K2 server no longer has the ability to edit AAD properties. AAD-based SmartObjects, used by the AAD workflow wizards, are no longer able to update AAD data. If you need to use the wizards or the SmartObjects directly, you must manually configure the AAD service instance to use the Azure Active Directory Management for K2 app. See Azure Active Directory Management for configuration steps.