This article is intended to answer frequently-asked questions about K2 Cloud in terms of security, permissions and rights, the K2 apps, integration with AAD and Office365, and other general topics.

You can jump directly to a section in this article using the links below:

General Questions

The table below briefly lists the available apps for K2 Cloud. See the Applications topic in the User Guide for more details on the available applications, a decision flow chart to identity which applications are required, and what access the applications require.

Application NameMandatory?Notes
K2 for Office 365 Yes* Provides integration with AAD and SharePoint, such as AAD Identity Caching, reading AAD user information, and reading and writing to SharePoint Online. This app is required if you integrate with SharePoint Online. If this app is used, then the Azure Active Directory for K2 app is not required.
Azure Active Directory for K2 Yes* Provides integration with Azure Active Directory, such as reading and caching AAD user information. This app is required if you do not use the K2 for Office 365 app to integrate with SharePoint Online.
K2 Cloud for SharePoint No This Provider-hosted SharePoint Add-In provides integration with SharePoint Online. This is provided as a download and installed into your SharePoint Online tenant's App Catalog during the K2 Cloud provisioning process. This application is required when integrating with SharePoint Online.
K2 for AAD Login No This app provides authentication against an AAD environment when using the SmartObject OData API for consumption of SmartObject data within third-party clients such as Excel, Power BI, and Tableau, and authenticates K2 Cloud users when using the Remote Package and Deployment (P&D) to migrate solutions from one environment to another. This app is required for K2 Cloud when Package and Deployment or OData API access is used.
Azure Active Directory for K2 Management No This app is used by the AAD service type, and enables K2 to create, update and delete AAD user information, for example when creating employee onboarding or offboarding applications. This app is optional, but must be installed if a customer requires the ability for K2 to make create/update/delete modifications against AAD.
K2 for Office 365 Mobile No Provides authentication against a customer’s AAD environment when using the K2 mobile and K2 workspace apps for iOS and  Android.
K2 for Exchange Online No This app is required if you want to use the Exchange Online feature to be activated, and provides K2 the ability to integrate with Exchange Online.
*Note: Either K2 for Office 365 OR Azure Active Directory for K2 must be installed. The functionality in Azure Active Directory for K2 is contained in K2 for Office 365, but K2 for Office 365 includes additional functionality to allow your K2 Cloud tenant to integrate with your SharePoint Online subscription. 
It is possible for a K2 Cloud tenancy to connect to on-premises data sources, but this may require additional services or subscriptions such as K2 Cloud Site-to-Site (S2S) VPN or K2 Cloud Secure Data Access. For more information on the available approaches you can use to connect a K2 Cloud environment to on-premises systems, please see the KB article KB002939: Connecting to On-Premises Data from K2 Cloud

With regard to user identities and connecting to on-premises systems: while AAD can be populated with user and group information federated from on-premises AD stores, the accounts within AAD are technically separate instances of a given user’s account. For example, if a company has a user Bob, Bob might have an on-premises AD account (bob@company.com) as well as an AAD account (bob@company.onmicrosoft.com). If customers have configured to access on-premises data systems, it is likely that the on-premises system that is expecting AD credentials will have no concept of AAD-based user context (token). Certain K2 SmartObject integration capabilities (such as, but not limited to, the ability to impersonate users and pass user credentials through to the on-premises system) may be limited or unavailable in these situations.
K2 Cloud can connect to a number of third-party systems, typically through SmartObject Service Types although other approaches may also be available. Please refer to the Product Compatibility, Integration and Support article for details on the various technologies and versions of third-party systems and software that K2 Cloud can integrate with.
This is the unique domain name that will be used when creating the URL for the K2 Cloud instance, and is essentially the 'friendly' display name for the K2 Cloud identifier (KUID) of the tenancy. The Vanity Domain must be globally unique for every K2 Cloud tenancy, and will be checked to make sure that the value entered is unique. You can only enter the value or word(s) before the .onk2.com domain. For example, you may choose mycompany.onk2.com as your Vanity domain value. Customers with multiple tenancies frequently use a convention that identifies each of their K2 tenancies, for example mycompany-dev.onk2.com and mycompany-qa.onk2.com.

The following additional restrictions apply:
  • Alphanumeric characters can be used (A-Z,0-9)
  • Dash "-" can be used (e.g. my-company@onk2.com)
  • No other special characters (e.g. !@#$%^&{} etc.) are allowed
This is an AAD account in your company, provided in email format. This account must be part of the Global Administrator Role in Azure AD. This account will set up the trust relationship for authentication, and this will also be the first K2 Admin to grant access for others. You can find more information about Office 365 admin roles here.
This is the data center where the instance of K2 Cloud will be provisioned.
The environment type is one of three types: Development, UAT or Production
This field is required if you plan to integrate with SharePoint, and is the URL of your SharePoint Online Tenant, for example mycompany.sharepoint.com.
No, K2 Cloud uses Microsoft's Exchange Online service and all system-generated emails will share a generic service address that is unique per K2 Cloud tenant. The email address will be in the format K2Service <KUID@onk2.com>, where KUID is the unique system-generated identifier for your K2 Cloud subscription. However, the display name of the email address can be changed from K2Service <KUID@onK2.com> to a friendlier name such as MyCompanyK2Service <KUID@onK2.com>. Please contact K2 Support to change the display name of your K2 From email address.

You should ensure that the domain (e.g. onk2.com) used by the K2 service is whitelisted in your email system so that your users can receive emails generated by K2 and K2 applications.
Yes, and the Servers topic describes how to obtain the IP address for your K2 Cloud tenant. Note that the IP is not guaranteed to be static for all time, since it may change if the environment is shut down for some reason such as end of subscription, payment issues, moving to newer gen hardware or so on). For whitelisting the IP in your firewall/for security purposes, you can assume that your K2 tenant will use the IP as reported in the Server node of the K2 Management site.
The consent process when enabling the K2 Workflow REST API with AAD was designed and built before Microsoft’s latest MFA implementation, therefore it won’t work unless MFA is disabled. Once consent is granted to the app, you can enable MFA again. The consent given to the app does not affect MFA consent for normal runtime operations.
No, an OAuth token is a scope grant, and permissions can still be more restrictive than a token scope. While the K2 app needs to be delegated permissions that require a tenant administrator, such as Sites.FullControl.All in SharePoint, users who do not have this level of access will not automatically get it when K2 is integrated with SharePoint. Only the K2 app is granted this level of access for use in workflow steps such as Create Subsite.

Azure Active Directory (AAD) and Authentication

K2 Cloud is built and hosted on Microsoft Azure, and relies on AAD for authenticating users, as well as resolving user and group information. AAD is therefore the only supported authentication mechanism to authenticate users that need to connect to K2 with user credentials. Users logging into your tenant must be valid AAD users and log in with an email address like bob@denallix.onmicrosoft.com and a password.

The integration between K2 Cloud and Azure requires identities provided by AAD. For K2 Cloud to communicate and integrate with a customer’s AAD subscription, K2 will provide the customer with an Azure Active Directory for K2 application that will need to be loaded by the customer into the customer’s AAD tenant. This AAD app authorizes K2 Cloud to utilize the AAD API, provided by Microsoft Azure Active Directory, to perform identity caching and other requirements to operate K2 Cloud. See this Microsoft article for more information on AAD subscriptions.
All user identities who need to authenticate with K2 must be resolved against AAD. How an identity is proven to AAD does not impact K2, since K2 only requires a valid AAD token for authenticating a user, and must be able to resolve identities against AAD.K2 Cloud will not have any direct interaction with other identity stores (such as on-premises Active Directory) and will only integrate with and authenticate users against AAD.

AAD does allow you to configure other identity providers as the source of user and group information - this is typically called 'Federation'. You can configure federated identity providers with K2 Cloud as long as the user identities reside in AAD. It is therefore possible to use another Identity Provider with K2 Cloud, based on delegated authentication from AAD to the third-party Identity Provider. AAD is still required for authentication with K2 Cloud. The request that initially authenticates against AAD must be able to reach the federated identity provider service. In most cases for ADFS, this is a system that is available in a customer’s DMZ between the public internet and internal systems or within their Azure Subscription, which passes an authenticated token back to AAD.

You can leverage Active Directory Federation Services (AD FS) with AAD when AD FS is configured as described in the Microsoft article Azure AD Connect and federation. AD FS enables using other Identity Providers (for example Okta and Ping), if user UPNs from the Identity Provider are present in AAD via Azure AD Connect. See the knowledge base article KB002433 How To: Configure Okta to Log In to K2 Sites for an example.
K2 uses the Microsoft Windows Identity Foundation which means that only relying party trusts configured for the WS-FED protocol that issue SAML 1.1 or SAML 2.0 tokens are supported.
K2 Cloud customers are responsible for populating, managing and maintaining their AAD subscription. K2 Cloud does not inherently import, maintain or edit data in AAD. However, If you added the Azure Active Directory for K2 Management app to your K2 Cloud subscription and granted the necessary consent, applications built with K2 can create, edit and delete accounts in AAD as part of the application, for example employee onboarding applications.
The FREE edition is the minimum requirement for K2 to use AAD; this provides a customer with up to 500,000 objects to manage (roughly analogous to a user) and should be good for almost any customer type.  Additional AAD editions bring more features and capabilities, but these capabilities are typically less focused on K2, and more on the individual needs of the customer.
No, user passwords are not stored or cached by K2. Once a user provides a valid username and password to Azure Active Directory (or a federated authentication system) that system will provide a token within the authentication flow that represents a valid and authenticated user to calling systems such as K2 Cloud. K2 never has access to or knowledge of a user’s password. K2 only caches a fixed set of user and group properties to improve performance when looking up user or group information. For more information see Identity and Data Security in K2 Cloud for SharePoint
Since K2 never prompts for credentials nor does the K2 server store passwords, these credential prompts are always from AAD. For more information about token lifetime, see Microsoft’s article Session timeouts for Office 365
Yes. A single AAD tenant can be utilized by multiple K2 Cloud tenants, for example using the same AAD tenant against your Production, QA and Development K2 Cloud tenants.
No. For example, should you create a K2 Cloud tenant against a temporary/evaluation AAD tenant, you cannot 'move' the K2 Cloud tenant to another AAD in the future. You would have to create a new K2 Cloud tenant to integrate with the new AAD tenant, and use tools like K2 Package and Deployment to move your K2 solutions to the new K2 Cloud tenant.
No, you cannot utilize multiple AAD tenants in a single K2 Cloud tenant. The integration model between AAD and K2 Cloud was designed with a single AAD tenant in mind. Microsoft provides two technologies that aim to solve multi-AAD requirements:
  • Azure B2B - allows one AAD identity to be invited to another AAD tenant as a guest to partake in collaboration or other workloads. Common scenarios here are when an organization wants to invite partners or sister organizations to collaborate, and the external organization's identities would be created within the customer's AAD tenant, but authentication of the user identity is still handled by the other organization's AAD tenant. This is similar to using a federated Identity Provider to populate your AAD tenant. For more information about support for K2 Cloud + Azure B2B, please see the KB article KB002501: K2 Cloud and External Users with Azure B2B
  • Azure B2C - allows external users with social logins (for example Facebook, Google, etc.) to be invited into scenarios where they can be authorized with AAD, but authenticated with the social provider.  This approach creates a wholly separate AAD tenant within a customer's primary Azure subscription and a customer would not be able to use both primary AAD and Azure B2C AAD concurrently. Currently, K2 Cloud does not support Azure B2C configurations because these configurations result in multiple AAD tenants.
K2 Cloud does offer the capability of allowing anonymous users to interact with your K2 applications, for example creating anonymous forms to capture user input without having to authenticate the user who is using the form. For more details on these capabilities and licensing implications, please contact your K2 representative.
AAD Permissions
    • Read Directory Data: Allow the application to read data in your organization’s directory, such as users and groups
    • Sign in and read user data: allow the application to sign into Azure Active Directory to read user data. This does NOT include passwords: K2 cannot read user passwords
Consent is the process of a user granting authorization to an application to access protected resources on their behalf. In K2 Cloud, an Azure Global Administrator must consent to allow the Azure Active Directory for K2 app to access data stored in the organization's AAD tenancy, and for this consent to apply to all users within the tenancy. K2 requires a Global Administrator to grant this consent (known as Admin consent flow) so that the consent is allowed for all users in your tenancy, and not only specific to one individual user.
Notice in the below image that there are green ticks in the “Requires Admin” column. This means that, in order for a regular user (a user that is not a global administrator for the tenant) to sign in, a global administrator must first have signed in and consented to the app's request permission on behalf of the organization. If a regular user attempts to sign in, they’ll be confronted with an error message such as: "Calling principal cannot consent due to lack of permissions". To learn more about the Microsoft Consent Framework that underlies this requirement, please see the Azure Active Directory consent framework topic in Microsoft's documentation.
AADConsentPermissions
If the requested permissions change, such as if a K2 app is updated to include new functionality that needs another permission or Azure permissions change, you may be prompted for tenant administrator permissions again. It can also happen on upgrade or whenever you run the Registration Wizard on your app catalog. Furthermore, if a token is being created for the K2 service account identity, which is at the scope of an application permission, K2 appends a URL parameter ?prompt=true. This ensures that the K2 service account identity can request and receive an app-only token. These are different than standard user tokens. For more information about app-only tokens, see Microsoft’s article Accessing SharePoint using an application context, also known as app-only.

SharePoint Online and O365

K2forO365Permissions
  • Read Directory Data: Allow the application to read data in your organization’s directory, such as users and groups.
  • Sign in and read user profile: Allows the application to read user profiles and to read basic site info on behalf of the signed-in user. This permission is not used.
  • Have full control of all site collections: Allows the application to have full control of all site collections on behalf of the signed-in user. SharePoint honors security so if a user does not have permissions to actually create, edit, delete or access a SharePoint site, they cannot do that through K2.
  • Read and write managed metadata: Allows the application to read, create, update, and delete managed metadata and to read basic site info on behalf of the signed-in user. The write permission is not used.
As described in the K2 Cloud - Service Polices, for customers looking to integrate K2 Cloud with SharePoint Online: "An O365 subscription that supports third-party developed apps being deployed into the customer’s tenant is required.". Typically this means that a customer will have either an E1 (or greater) subscription or an F1 subscription.
No, you do not need SharePoint Online or Office 365 to use K2 Cloud.
No. Since K2 integration with SharePoint uses the following features, it must request Full Control
Permission Description Dependent permissions Included in these permission levels by default
Manage Permissions Create and change permission levels on the website and assign permissions to users and groups. View Items, Open Items, View Versions, Browse Directories, View Pages, Enumerate Permissions, Browse User Information, Open Full Control
Create Subsites Create subsites such as team sites, Meeting Workspace sites, and Document Workspace sites. View Pages, Browse User Information, Open Full Control
Manage Web Site Grants the ability to perform all administration tasks for the website, as well as manage content. View Items, Add and Customize Pages, Browse Directories, View Pages, Enumerate Permissions, Browse User Information, Open Full Control
Create Groups Create a group of users that can be used anywhere within the site collection. View Pages, Browse User Information, Open Full Control
Enumerate Permissions Enumerate permissions on the website, list, folder, document, or list item. Browse Directories, View Pages, Browse User Information, Open Full Control
No, because Graph site permissions are only available for All sites and do not have this level of granularity. For more information, see the ‘Sites permissions’ section of the Microsoft Graph permissions reference.
Yes, between app deployment and app activation, you can choose which site collections get the K2 app activated to them.
K2 does not control what permissions AAD designates as needing tenant administrator to give consent for the permissions. As a case in point, a read-only permission scope for managed metadata requires an administrator to give consent. While this may seem a bit extreme, as consumers of these requirements, K2 has no other option than to request this higher level of consent. For more information, see the ‘Sites permissions’ section of the Microsoft Graph permissions reference

Infrastructure

Exchange Online by Microsoft
Yes
Yes

Additional Resources

You may find the following resources valuable for much more information on K2 Cloud and security in K2.