Celonis Product Documentation

Action Flows predominantly interact with third-party applications through Application Programming Interfaces (APIs) that are created, maintained, and enhanced by those services. While each API is different, the vast majority of these APIs are based upon industry standard protocols and architectural patterns such as Restful or SOAP-based communication over HTTPS.

For Action Flows to work securely with any given third party application, Action Flows must adhere to the authentication and authorization principles implemented within the API of the third party application. This ensures that each call to that third party API is capable of pulling or pushing information in a secure and auditable manner.

While there are many different technical methods for authentication and authorization in use by many different third party applications, Action Flows most commonly leverage the widely-accepted, industry standard OAuth 2.0 authorization framework. This framework is widely adopted among the most security-conscious, enterprise-grade, web-based applications including those created and maintained by Google, Microsoft, Salesforce, and Adobe. This protocol provides methods by which users within Action Flows can authorize Celonis Platform to interact with a third party application on the user’s behalf and allows that user to maintain control over the authorization. In the context of this framework, Celonis Platform is operating as the “client” and any third party application connected to the Action Flows is operating as the “authorization server” or “resource server”.

When a user within Action Flows in Celonis Platform first wants to connect to a third party application that uses an OAuth 2.0 Authorization Code flow, the following steps are taken by the user, the third party application, and Action Flows as a part of the Celonis Platform platform.

Action Flows utilize encryption of data at rest and in transit to protect its confidentiality.

Data at Transit

Data sent between client browser and the Celonis Platform platform are always encrypted. The Action Flows solution supports TLS1.2, TLS1.3 for encrypted transfer.

Data sent between Action Flows and third party application depends on which protocols the third party application supports. Action Flows will always negotiate the most secure approach available by the application.

Data at Rest

All data at rest is encrypted at the file system level by AES256. Sensitive data like user credentials are encrypted in the database per object by additional AES256. Passwords and tokens are also hashed using PBKDF2-SHA512 with 200k iterations. Cryptographic keys are managed using the key management system of the underlying cloud provider.

Virtually all third party applications require the ability to identify a specific user associated with each interaction within the application or through its API. Users may authenticate with a 3rd party application using either a service account or a personal account. Both account types are common within enterprise integration patterns and either may be used within the Action Flows, depending on the desired use case and security requirements.

Service Accounts

Administrators of third party applications will commonly create service accounts that represent another application or process, instead of a human being, in order to provide the appropriate security context. Credentials for such an account may be stored and managed by a select group of people, rather than being maintained privately by only one person. All actions done by a service account (for example, accessing, editing or creating a record in a third party application) can only be attributed to that service account and anyone who had access to the account. For example, a large corporation may opt to create a special email account “corp_support@acme.com” with a password shared by multiple people.

Personal Accounts

Personal accounts are simply a set of credentials used by an individual person and that person only. They provide the appropriate security context for that user and actions done by the account can be attributed only to that user under normal circumstances. For example, most companies provide a personal account for each employee for managing their own email.

When Celonis Platform is interacting with a third party application through an authorized user consent, Action Flows are operating within the same security context as that user. As such, Celonis Platform is unable to perform any actions (read, create, delete) in the third party application that the user is not authorized to perform. At a minimum, the same permission restrictions that are enforced when the user logs into the third party application are enforced by the application’s API.

In addition to the general boundaries that are constrained by the user context, many third party applications also employ scopes to further restrict what Celonis Platform is authorized to do on the user’s behalf within the third party application. A scope typically represents some specific capability to access data or perform some action such as the ability to read emails or the ability to send emails. Each third party application is able to define and utilize the available scopes according to their own needs. For more information on scopes, see the Datatracker documentation.

Action Flows’ apps that interact with third party applications that employ the OAuth 2.0 authorization framework and scopes, are designed to request the minimally required scopes in order to perform the desired action within the third party application. This concept is known as the principle of least privilege (PoLP) within application security best practices.

If a user later requests to perform additional actions within the third party application through Action Flows, then Action Flows will automatically direct the user to authorize the expanded scope(s), as required. This process is known as incremental authorization and ensures that users are given maximum control to determine which actions Celonis Platform can perform on their behalf, without extending permissions beyond what is necessary.

Different third party applications deployed within an enterprise environment may require additional processes to be followed in order to enable an end-user to grant Celonis Platform to operate on their behalf.

As a common example, apps that are managed within an enterprise deployment of Microsoft Azure may require an administrator's consent in addition to the end-user’s consent. Microsoft Azure administrators may configure consent policies such that a specific app (within Action Flows) does not require any admin consent, requires admin consent through defined approval workflows, or is restricted entirely from use. For more details, see Microsoft documenation. Optionaly, Microsoft Azure administrators may also choose to create their own application to be used with Celonis Platform with their own designated permissions

When Action Flows initiate an authorization flow with a third party application, it sends important details to the third party application that uniquely identify Celonis Platform as the solution that the end-user wishes to authorize to act on their behalf.  These details include a client identifier and a client secret.  In order to support these common authorization flows, the Celonis team has registered the Celonis Platform solution with each OAuth 2.0-based third party application.  During this registration process, the Celonis team previously provided details about the Celonis Platform Action Flows solution, including security and privacy details, for review by the third party application. For more information on client registration, see the Datatracker documentation.

This process enables authorized users of the Celonis Platform platform to quickly and securely authorize Celonis Platform to interact with the third party solution on their behalf.  However, some advanced users or security teams with strict controls may wish to create and register their own client with some third party applications.  Doing so can enable those users to provide even more restrictions placed on the authorization and independently manage advanced concepts such as API rate limits for interactions with the third party application.  The specific capabilities and benefits of registering and managing your own client application with the third party application vary with each third party application provider.

Examples of third party application client registration processes include: 

Once a new client registration has been completed, Action Flows’ users can click on “Advanced” settings while creating a new connection and enter their own client ID and secret rather than using the default client ID and secret.