Security details for Action Flows and third party applications
Action Flows are a low code, API-based integration platform in the Celonis Platform (Celonis Platform) which customers can use to automate their tasks and business processes. Action Flows integrate with Celonis data and intelligence, support 10,000+ out-of-the-box actions across 1,000+ systems (cloud, on-prem, custom), and provide a no-code user interface for configuration. This document describes core concepts and principles utilized throughout Action Flows and within those third party applications to apply and adhere to best practice industry security standards.
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.
User authenticates to the Celonis Platform platform.
Additional authentication mechanisms such as two-factor authentication may be employed to verify the identity of the user within Celonis Platform.
Based upon the user’s permissions within Celonis Platform, they may be able to access the Celonis Platform Studio and create a new connection to a third party application within a particular package within the Action Flow designer.
While creating a new connection to a third party application, the user is directed to the third party application’s authentication page wherein they must provide valid credentials to access the third party application. Users may use a service account or a personal account during authentication based upon their business and technical requirements. For additional details, see Account Types.
All enhanced authentication mechanisms required by the third party application are also required here, including two-factor authentication.
Note
At no point in time during this flow does the user enter credentials for the third party application into Celonis Platform Action Flows. This is one of the major advantages of this framework and it enables Celonis Platform to never store usernames or passwords for those third party applications.
Once authenticated to the third party application, the user is presented with an authorization prompt by the third party application. The prompt requests the user to confirm or reject authorization for Celonis Platform to interact with the service on their behalf. Most third party applications will also specify a set of specific permissions that can be given to Celonis Platform with this authorization. These permissions are known as “scopes” and can limit what Celonis Platform can do on behalf of the user within the third party application. For more details, see Scopes and Permissions.
Note
Some third party applications may require additional approval steps by internal IT teams before end-users can authorize Celonis Platform to operate on their behalf. These approval steps will differ for each third party application and deployment within an enterprise. For more details, see Common IT Approval Processes.
Once a user confirms that they would like to authorize Celonis Platform to interact with the third party application on their behalf, they are returned to the Action Flows interface wherein they can continue to configure the ways in which they wish to automate or integrate the third party application.
During this process, Action Flows and the third party application exchange a set of identifiers, secrets, codes, and tokens according to the OAuth 2.0 framework and the third party application’s specific implementation of the framework.
Importantly, this framework leverages mechanisms by which access tokens (secret strings that enable authorized API calls) routinely expire according to best practice security principles. When an access token is about to or has expired, Action Flows have built-in mechanisms to automatically refresh these tokens according to the OAuth 2.0 framework and the third party application’s implementation.
All tokens stored in Action Flows are stored encrypted per object with AES256 and hashed with PBKDF2-SHA512 algorithm.
|
|
|
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:
Google Workspace (Drive, Calendar, Gmail, etc.); see Setting up OAuth 2.0
Microsoft services that use Microsoft Identity Platform (Teams, 365 Calendar, 365 Email, etc.); see Register an Application with Microsoft Identity Platform
Salesforce; see Create a Connected App
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.
