K2 Cloud: Authentication, Security and other Frequently-asked 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.

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.

What systems can K2 Cloud integrate with?

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.

• 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

Onboarding: What is the "Global Admin FQN"?

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.

Onboarding: What is the "Azure Data Center"?

This is the data center where the instance of K2 Cloud will be provisioned.

Onboarding: What is the "Environment Type"?

The environment type is one of three types: Development, UAT or Production

Onboarding: What is the "SharePoint Online URL"?

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. When requesting your IP to be whitelisted, please make sure to provide the CIDR IP address or range to your support case. As an example, you can use the following website which will provide you with the CIDR IP address or range:

https://www.ipaddressguide.com/cidr

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.

All dates are recorded in UTC (Coordinated Universal Time). If you migrate to K2 Cloud from other systems you must convert your data table views and stored procedures to UTC before migrating.
 

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.

• 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.

• • 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.

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.

• 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, 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

Exchange Online by Microsoft

Yes

Yes

A K2 Cloud environment's application data resides solely in the tenant database, stored in Azure SQL. Each environment’s application data is completely separated from any other customer and/or environment’s data through database level separation

The environment database is based on Azure SQL and utilizes Azure SQL's business continuity features. Specifically, automated backups in read-access geo-redundant storage (RAGRS) to provide geo-redundancy. In the event of a major failure on data, database server or datacenter level, a point-in-time restore (PITR) of the database can be performed

At a minimum of once every 12 months and more often when possible or necessary, a disaster recovery and data restoration drill is performed. This consists of Simulating data tier outage, Recovering, and validating application integrity post-recovery. The tests include the simulation of failures at various levels – network, compute, data, database, database server, and datacenter outages. The applicable recovery and restoration events are captured for audit purposes of certifications such as ISO27001:2013 and SOC 2 Type 2.

Generally speaking, the Database Recovery Point Objective (RPO) is 1 hour or less, the Disaster Recovery Time Objective (RTO) is within 48 hours after the DR event, and the Data Backup Retention Period for PITR is 14 days of backup data. Some considerations may impact these objectives and associated SLA's, please refer to your subscription agreement for more details.

The standard Disaster Recovery Policies described in the K2 Cloud Service Policies are included for all levels of K2 Cloud subscriptions. Alternative RPO and RTO capabilities are available for a customer’s production tenant - additional charges will apply. For any alternative or better-than-default RPO and RTO capabilities, additional infrastructure is required which typically means doubling of resources and therefore cost.

Data restoration services can be requested via a Technical Support Ticket by the customer. A maximum number of 1 data restoration request per annual subscription period is included free of charge. Additional requests will be charged for at standard K2 Professional Services rates.

K2 Cloud typically acts as middleware and interacts between various systems based on workflow tasks, escalations, or other mechanisms. Restoration and re-activation of restored workflows might cause unexpected issues, such as duplicated transactions in other systems or re-escalations. As these issues may be solution-specific, K2 professional services can be engaged to investigate the impact of restoring a K2 Cloud database to a specific point in time. The above-mentioned impact will be limited to the duration from the point-in-time restoration point (PITR) up to the time the service is restored: RPO + RTO.

Data restoration and/or recovery can take a long time due to various factors such as the size of the database, the performance level of the database, the number of transaction logs involved, the amount of activity that needs to be replayed to recover to the restore point, network bandwidth if the restore is to a different region, and the number of concurrent restore requests being processed in the target region. Cloud Operations will start the DR recovery process once it becomes clear from the evidence gathered at the time, from all parties involved, that the outage may last longer than 24 hours; or 24 hours after an outage was identified and after the customer has been notified of, and agreed to, K2 Cloud Operations' planned action.

Apart from the fact that the customer is notified of the pending restoration activities and will have to validate successful recovery/restoration after the fact, there should be no other action on the part of the customer in a DR scenario. In the case of data restoration, all communication about the request, status updates, completion notification, and successful validation by the customer will occur through a Technical Support Ticket. In a DR event, all of the above communication will be through both a Technical Support Ticket (for reporting and auditing purposes) as well as the Customer Success Manager.

In the event of a wide-spread Service outage incident, Service Operations will prioritize the restoration of production instances over non-production instances initially. From there, additional triage will be performed on production customer tenants based upon factors such as tenant criticality and size, at the discretion of K2 Cloud Operations.