Platform security

• 1: Workspace security
• 2: Process security
• 3: Single Sign On (SSO)
• 4: Data residency

1 - Workspace security

There are a number of different ways of setting security within your Kianda workspace. Security refers to both access to processes as a Designer, and access to process instances.

Security privileges by role

The Kianda platform allows for different security privileges to be set for different types of users, making administration of users and their access rights easy to manage. The following are the different roles users can be assigned on Kianda – each has certain default permissions:

• User – can only access what is assigned to them. For example, forms and dashboards.
• Administrator – can access (view and edit) all published processes. Can only edit draft processes that they have created themselves or for which they have been made Process Administrators.
• Manage partners/customers – can only access the essentials to manage customer portals; that is, they can use the Invite partners function under the Administration menu.
• Design business process – can only design business forms and workflows using Kianda Designer
• Manage data sources – can only manage data sources and connections, namely the Data sources function
• Developer – can design new widgets within the platform using the Developer function

In addition to default permissions, you can also create user groups and assign ownership and/or access to processes or dashboards as needed. Security settings can be applied to dashboards or particular widgets within a dashboard so that they are only visible to certain users or groups of users; and data source connections can be configured in the same way to ensure the highest access control levels. We will now look at different ways of assigning access and controlling security.

Process administrators

When an Administrator creates a new process in Kianda, they can set who they want the Process Administrators of that process to be (anyone chosen to be a Process Administrator needs to be someone who has an Administrator role, so that they have access to the Designer function to be able to edit the process). The Process Administrators can be individual users, groups or a combination of the two.

If you are an Administrator, you can edit a process you have created and set the Administrator role for that process by clicking on the Edit process button (Pen icon) in the main process view. Choose the user(s) and/or groups you want to be the Process Administrator(s) in the Edit process dialog box.

Setting process administrators in the Edit process dialog box

In the example above, Vikky was already a Workspace Administrator who had access to the Designer function in Kianda – now that she has been assigned to be the Process Administrator for the Maintenance Process, this means that she can edit the draft process design.

Form ownership

When you create a process in Kianda, you can then set a default owner for each form you create within that process. Only Form Owners can edit individual process records. For example, if a ‘Maintenance Request Process’ is initiated from a dashboard, then the default Form Owner, regardless of their role (that is, regardless of whether their ‘role’ on Kianda is ‘administrator’ or ‘user’ etc), will be able to edit information submitted in new process records from that form.

If you are a Workspace Administrator and you’ve created a new process that contains a form, you can set the default owner for that form by opening the process in Kianda Designer, selecting the form and clicking the Edit form button (Pen icon). This opens the Edit form dialog box within which you can choose from individual users, groups or a combination of both under Default owner(s).

Quick actions within forms

Within the Edit form dialog box, you can select the Enable quick actions checkbox so that options to Enable re-assign, Enable edit and Enable custom action appear. From here, a Process Administrator or form designer can give individuals, groups or a combination of both, the ability to have process instances assigned to them, to enable them to edit in process records and custom actions of their choice.

Edit form dialog box

Select the Enable quick actions checkbox, then select one or more of the checkboxes for the three options that appear below it (as shown in the image). For each of the options you select, click on the ellipsis button and select from Users, Groups and Partners, and/or check the box to Allow form owners the particular action – for example, re-assignment means the chosen users can click on the quick action button in the form and reassign the form to someone else.

What’s next

Now that you’ve learned about Workspace security, find out more about other security access levels:

• Process level security
• Single Sign-On
• Data residency

2 - Process security

Introduction

In addition to Workspace security that is setting levels of access by role and form ownership, there are a multitude of ways to set access at a process, field and dashboard level. The following sections describe security at different levels.

Process security settings

When you are creating or editing a process in Kianda Designer, you can set security settings for that process. This setting will apply to every record (instance) created from that process. To do this, click on the process in Designer and then, in the right-hand pane, click on the Settings button and select the checkbox beside Enable process security.

Choose an individual user, groups or partner or combination, to be ‘security users’ and then choose from one of three security modes, as shown in here.

Process security settings

The three available security levels are listed from lowest to highest. For example, if you choose Security users only can create, view and update means that only the users listed as Process security users – in the example shown here, Mike Balcoome and the Management Team – will be able to access and view process records. No other users will have access to the process records generated by this process.

Process security rule

Another way to set security is to use one of the Workflow rules called Process security to dynamically change the security settings for a process record (instance). Using this rule allows you to set the same security modes shown in the process settings above, but this can happen based on a particular condition or trigger – for example, clicking the Submit button.

To add this rule, open your process in Kianda Designer and select the relevant form. Then, in the left-hand pane, go to Add a rule > Workflow > Process security. In the Edit rule – Process security dialog box, create a condition if desired, and then choose from the type of users who will become security users. Choose from the options: Override to override existing security, or Append if you want to add a new level of access. Click the Enable security checkbox to choose a Process security mode.

Edit rule – Process security dialog box

Panel and button security

In addition to process and form level security, you can set panel and button security by clicking on a panel or button within a form. Click on the panel or button of choice, click the Edit button (Pen icon) and choose Yes beside Enable security. Click on the Add security button to add users or groups to enable access to the button or panel.

Panel security within the edit field dialog box

Dashboard security

As an end user, when you login to Kianda, you are presented with dashboards and widgets for different processes. The dashboard is made of multiple widgets like tiles, charts, links and lists. Go to Dashboard to find out more about each widget type. You can set security at both a) dashboard level and b) widget level, see Widget security for more details. This section will deal with dashboard level security.

Dashboard level security can only be applied if you have the Administrator role to allow visibility of dashboards and widgets.

To apply security to dashboards:

1. Go to the existing dashboard page by clicking on Dashboard and the page name in the left-hand side menu.

2. Click the Edit button visible in the top menu bar.

3. Now in Edit mode, the Settings button is visible. Click on the Settings button.

4. The Edit dashboard page dialog box appears where you can find the Visible to user picker with an option to select Users and/or Groups.

   

5. Select the correct Users and/or Groups using the dropdown menu.

6. Make any other changes you need to the dashboard, see Dashboard for more details.

7. Click on OK when you are finished editing the dialog box or Close to exit the dialog box at any time.

8. Save the changes you make by clicking on the Save button at the top of the page.

Widget security

Similarly, you can set the visibility for an individual widget on the dashboard like a tile, chart, or list, for example, if you want the dashboard to be visible to everyone and a particular chart on the dashboard only visible to management. This can be achieved by setting the visible to field to the management group as shown below.

To apply security to a dashboard widget:

1. Go to the existing dashboard page by clicking on Dashboard and the page name in the left-hand side menu.

2. Click the Edit button visible in the top menu bar.

3. Now in Edit mode, click on the Cog/settings button of the widget.

4. The Edit widget dialog box appears where you can find the Visible to user picker with an option to select Users and/or Groups. The example below shows the dialog box for a List widget.

   

5. In the Visible to field select the correct Users and/or Groups from the dropdown menu.

6. Click on OK when you are finished editing the dialog box or Close to exit the dialog box at any time.

7. Save the changes you make by clicking on the Save button at the top of the page.

What’s next

Now that you’ve learned about Process level security, find out more about other security access levels:

• Workspace security
• Single Sign-On
• Data residency

3 - Single Sign On (SSO)

Single Sign-On (SSO) is an authentication process that allows a user to log in with a single ID to any of several related, yet independent, software systems. Single sign-on allows the user to log in one time and access services without re-entering authentication factors.

On Kianda, Single-Sign-On allows the user to login via Single Sign-On connector. This connector for example could be SharePoint, Office365 or Salesforce.

How to get started

To enable Single-Sign-On, follow the steps below:

1. Login to Kianda with an Administrator account.

2. From the left-hand side pane, click on Administration > Subscription > Details.

3. In the Single Sign-On Details page, beside Enable Single Sign-On click on Yes to enable Single Sign-On. If Single-Sign-On is already enabled and if you wish to disable it, click on No and then clear the cache memory and login to Kianda by entering your password first and then the username.

   

4. Choose a Single Sign-On Provider by choosing Office 365 or SAML.

   Office 365 allows Office enterprise users to Single Sign-On into their Office 365 account with a single username and password and from there to access web and Software as a Service (applications) like Kianda.

   Secure Assertion Markup Language (SAML) 2.0 enables individuals to access numerous web applications using one set of login credentials. It works by passing authentication data between an identity provider (IdP) and a service provider such as Kianda.

   • If you choose Office 365, you must choose an Office 365 Connector from a dropdown list. This will show Office 365 datasources already created in the Data sources function under Administration. Go to Office 365 data connector to learn how to create a data source if one doesn’t exist.

     ​

   • If you choose SAML 2.0, you must provide the SAML 2.0 Target URL. This is the identify provider (Idp ) URL. You can also provide the SAML 2.0 Token Signing Certificate (.cer) by clicking on Browse to navigate, find and add the cert, a .cer file to the details page.

     

5. For Auto redirect to SSO choose from No or Yes. If you choose Yes then users cannot login with their Kianda username and password directly, and are automatically redirected to the configured SSO provider for authentication.

   • However if you have an external set of users, for example contractor who need access to Kianda, you can set a SSO bypass group. You must define a group of users in advance, using the group creation option within the Users function under Administration. From here you can define a group of users that can login using Kianda’s username and password. Use this option for users that are external for the configured SSO provider, so they can go directly to the workspace login page to login.

6. For the option Default “Remember Me” to false choose from No or Yes, to remember the login credentials.

7. When you have completed your edits, click on Save Changes or click on the Back button at any time to exit the page without saving.

SAML assertion attributes

For successful authentication the following attributes must be passed to Kianda. Kianda will primarly validate the NameID and the UPN in second place while authentication a SAML 2.0 response.

1. NameID The existance of the NameID property with emailAddress format is required.
2. UPN The upn (user principal name) is recommended.
3. Emailaddress The emailaddress property is recommended

4 - Data residency

Introduction

Data residency refers to the actual physical location where data is held or stored for an organisation. For example data could be submitted by a user in Australia to a cloud application, but the servers that hold and process the data are in Europe, so the data residency in this case refers to the European location.

Data residency is particularly important to ensure that local laws and regulations are upheld in the country/region where the data resides. It is therefore important that customers using cloud applications are aware of their data’s physical location so that local laws are upheld. Knowing where a cloud provider’s data centres are will help to ensure that organisational data residency policies respect local laws.

The Kianda platform is a SaaS (Software as a Service) cloud-based solution, and allows for integration to multiple third-party IT systems / siloed data sources, for example SharePoint Online Environment and Active Directory, SAP, SQL Server, O365, Oracle and so on. The platform is hosted and secured in Microsoft Azure. This allows Kianda to specify the region where customer data will be stored and processed. The datacenter region for Kianda is North Europe, and therefore the location for data storage and processing is Ireland, see https://azure.microsoft.com/en-us/global-infrastructure/data-residency/#select-geography. This means that data residency for Kianda, is Europe, and therefore European laws like General Data Protection Regulations (GDPR) must be upheld.

Kianda Security and GDPR

Kianda Technologies confirm that the data for Kianda Platform (including backup and test data) are stored within the EU. For optimal performance our platform is deployed to Microsoft Azure Ireland with geo replication to Azure Netherlands.

The Kianda platform is also available to be deployed and hosted on private cloud or on premises in client’s preferred geographical location. This setup will include its own backup policy and system. Our platform allows for data, including backup and test data, to be stored wherever it is most desirable for the Client for example SharePoint tenant.

Users’ IP addresses are stored in system logs for security and data protection purposes. We comply with our obligations under Data Protection Legislation by providing an adequate level of protection to any Personal Data.

In addition, the data is encrypted at rest and in transit. Data records are also masked from a GDPR point of view. We employ Microsoft security products to mask automatically, classify personal data which is scheduled on a weekly basis.

Personal data such as IP addresses is retained for a period of 12 months.

ISO27001:2013 Certification

In terms of security and quality, all Kianda services and solutions are ISO27001:2013 Certified, and as part of that are audited by an external party every 6 months. Details may be accessed here: https://www.kianda.com/information-security.

Kianda employs the highest levels of security as demonstrated by our ISO certifications, and includes extensive dashboard and reporting/audit trail functionality.

Kianda Technologies comply with all applicable laws and regulations regarding the protection of personal data. We provide separate production and test environments. Responsibility for maintaining test data is with data controllers, and in that regard, we treat both test and production environments as managed by the customer.

On termination of contract, as per our customer service level agreement we will destroy or otherwise dispose of any customer data in our possession unless we receive, no later than ten days after the effective date of the termination of this agreement, a written request for the delivery to the customer of the then most recent back-up of the customer data. We shall use reasonable commercial endeavours to deliver the back-up to the customer within 30 days of our receipt of such a written request, provided that the customer has, at that time, paid all fees and charges outstanding at and resulting from termination (whether or not due at the date of termination).

The Customer (data controller) shall own all right, title and interest in and to all of the Customer Data and shall have sole responsibility for the legality, reliability, integrity, accuracy and quality of all such Customer Data.

If we, as data processor, receive any request by any person to access all data, we shall within five (5) business days provide the Data Controller with the full details of that request.

Kianda would be pleased to participate in a Data Protection Impact Assessment (DPIA) at the client’s request. Furthermore, we confirm that our solution conforms with the principles of Data Privacy by Design and Default.