Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial draft of identity docs #5133

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions docs/self-managed/identity/orchestration-identity/configuration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
---
id: configuration
title: "Configuration"
description: "Learn about the Identity configuration options available in your Orchestration cluster."
---

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';

:::note
As a Spring Boot application, Camunda 8 supports any standard
[Spring configuration](https://docs.spring.io/spring-boot/reference/features/external-config.html) method.
:::

The following variables apply globally to all components within the Camunda Orchestration core: Zeebe, Operate, Tasklist, and Identity.

<!-- updates must be made to BOTH tables -->
<Tabs>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❓ what is the default config we want to refer to here? Because this differs by distribution, whether it's c8run or helm, based on the second tab it seems helm? I can then provide the actual defaults next. Some like SPRING_PROFILES_ACTIVE are also not relevant then as the user can't control them.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see in installation we refer to this as reference from a c8run perspective, I woudl thus suggest to have tabs by distribution c8run and helm. I would omit the ENV variable tab and instead extend the spring boot note by the fact that all properties can be provided as environment variables too, like we do in other places of the docs like here https://docs.camunda.io/docs/next/self-managed/zeebe-deployment/configuration/environment-variables/#environment-variables-for-configuration

Copy link
Contributor Author

@conceptualshark conceptualshark Mar 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally I think this guide should reflect Helm (and other production-ready distributions when ready) and not C8Run at all, as C8Run is unique, not for production, and its configuration requirements are largely handled on its own page. I assume that other production-ready distributions, when available, would reflect the same defaults as Helm?

We've historically had difficulty with users converting from Helm config to environment variables, and the docs team has discussed listing them out separately as we can - @akeller do you have any input here? My thinking was to start having this available for Docker and other distributions down the line, to prevent our docs from being as Helm-biased a they are now.

(Edit: Recognizing that Helm isn't ready for prod, either - but it will be!)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My current understanding is C8Run is for onboarding and non-production use cases to get up and running as quickly as possible (and maybe even, ideally, with no configuration?). Since we prioritize the Java Spring dev during onboarding, leading with the Spring configuration makes sense.

Once we start talking about production distributions, things are a bit unclear to me - what's our happy path or recommendation when it comes to config? Default config feels like a PM decision and I would defer to @FarkasRabai and/or @theburi.

I do think we need to be super explicit about Helm config vs. environment variables vs. properties and not expect our users to do the mapping themselves and add _ or . appropriately. We can't just say "follow this pattern" and document the configuration fully in only one way.

🤞 hope this helps. LMK if there if anything else I can clarify.

<TabItem value="env" label="Environment variables" default>

| Environment variable | Description | Default value |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------- | ------------------- |
| `SPRING_PROFILES_ACTIVE` | **Note:** This property will be deprecated as additional authentication methods become available. | `consolidated-auth` |
| `CAMUNDA_SECURITY_AUTHENTICATION_METHOD` | The authentication method to use. | `basic` |
| `CAMUNDA_SECURITY_AUTHENTICATION_UNPROTECTED-API` | If the API can be used without authentication. | `true` |
| `CAMUNDA_PERSISTENT_SESSIONS_ENABLED` | Enables shared authentication between the Orchestration web applications (Operate and Tasklist). | `true` |
| `CAMUNDA_SECURITY_AUTHORIZATIONS_ENABLED` | If authorizations are enabled. | `true` |
| `CAMUNDA_SECURITY_INITIALIZATION_USERS[0]_USERNAME` | The username of the first user. | `demo` |
| `CAMUNDA_SECURITY_INITIALIZATION_USERS[0]_PASSWORD` | The password of the first user. | `demo` |
| `CAMUNDA_SECURITY_INITIALIZATION_USERS[0]_NAME` | The name of the first user. | Demo |
| `CAMUNDA_SECURITY_INITIALIZATION_USERS[0]_EMAIL` | The email address of the first user. | `demo@demo.com` |

</TabItem>
<TabItem value="helm" label="Helm properties" default>

| Helm property | Description | Default value |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------- | ------------------- |
| `spring.profiles.active` | **Note:** This property will be deprecated as additional authentication methods become available. | `consolidated-auth` |
| `camunda.security.authentication.method` | The authentication method to use. | `basic` |
| `camunda.security.authentication.unprotected-api` | If the API cane be used without authentication. | `true` |
| `camunda.persistent.sessions.enabled` | Enables shared authentication between the Orchestration web applications (Operate and Tasklist). | `true` |
| `camunda.security.authorizations.enabled` | If authorizations are enabled. | `true` |
| `camunda.security.initialization.users[0].username` | The username of the first user. | `demo` |
| `camunda.security.initialization.users[0].password` | The password of the first user. | `demo` |
| `camunda.security.initialization.users[0].name` | The name of the first user. | `Demo` |
| `camunda.security.initialization.users[0].email` | The email address of the first user. | `demo@demo.com` |

</TabItem>
</Tabs>
101 changes: 101 additions & 0 deletions docs/self-managed/identity/orchestration-identity/installation.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,101 @@
---
id: installation
title: Initial setup
description: "Learn how Identity is bundled with your default Orchestration cluster."
---

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';

Identity is included by default with the deployment of any [Orchestration cluster](/self-managed/reference-architecture/reference-architecture.md#orchestration-cluster). Within an Orchestration cluster, Identity provides unified, cluster-level identity management and authorizations.

Identity for Orchestration clusters is available via [Helm install](/self-managed/setup/install.md), and for local development via [Camunda 8 Run](/self-managed/setup/deploy/local/c8run.md).

## Initial configuration

Following the default installation will result in a cluster with the following:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❓ what is the default installation, reading further it seems c8run?


1. Basic authentication enabled
2. API authentication disabled
3. Authorizations disabled
Comment on lines +19 to +20
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❌ this is only true for c8run, for helm we default to a secured setup and both are enabled, as the into mentions both distributions, let's label this guide as c8run specific?

4. An initial user with the username/password `demo`/`demo`
5. An `admin` role with read, create, update, and delete permissions for other roles, which is applied to the initial `demo` user

To make changes to the initial configuration, add the desired values via your `application.yaml` or environment variables according to the available [configuration properties](./configuration.md).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❌ you would need to use the --config flag of c8run to make use of an own config, see https://github.com/camunda/camunda-docs/pull/5145/files#diff-5f8b726fad04379e6db620802a56d8916fd1fb90956429487f4b16d80b88afcfR133


### Configure an initial user

The initial user created by the application will be assigned the `admin` role, and can be used for authentication to the web applications and additional role management.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔧 I'm not sure if it should be noted here or not but the admin role is assigned to all users who are set in the camunda.security.initialization.users list, long term we'd want to refine that IMO but for now thats the functionality


To create a unique initial user, the following is required in your `application.yaml` or environment variables:

<Tabs>
<TabItem value="helm" label="Helm properties" default>

```yaml
camunda:
security:
initialization:
users:
- username: <Your chosen username>
password: <Your chosen password>
name: <The name of the first user>
email: <The email address of the first user>
```

</TabItem>
<TabItem value="env" label="Environment variables" default>

```shell
CAMUNDA_SECURITY_INITIALIZATION_USERS[0]_USERNAME=<Your chosen username>
CAMUNDA_SECURITY_INITIALIZATION_USERS[0]_PASSWORD=<Your chosen password>
CAMUNDA_SECURITY_INITIALIZATION_USERS[0]_NAME=<The name of the first user>
CAMUNDA_SECURITY_INITIALIZATION_USERS[0]_EMAIL=<The email address of the first user>
```

:::note
Any other users included in the initialization `user` list will also be granted the `admin` role.
:::

</TabItem>
</Tabs>

### Enable API authentication and authorizations
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔧 this duplicates pending changes by #5145 shall we link from one to the other instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this differ at all if we look at this guide from a Helm default perspective? Otherwise the C8Run guide can point here, but that can be updated separately.


By default, basic authentication is enabled on the Camunda web applications, but the API is unprotected, and authorizations are disabled. API protection and authorizations can both be enabled by modifying your `application.yaml` or environment variables:

<Tabs>
<TabItem value="helm" label="Helm properties" default>

```yaml
camunda:
security:
authentication:
unprotected-api: false
authorizations:
enabled: true
```

</TabItem>
<TabItem value="env" label="Environment variables" default>

```shell
CAMUNDA_SECURITY_AUTHENTICATION_UNPROTECTED-API=false
CAMUNDA_SECURITY_AUTHORIZATIONS_ENABLED=true
```

</TabItem>
</Tabs>

:::note
To enable authorizations, API protection must also be enabled.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏻 this is a great point to note down, in the future we will look to make the application more defensive during start up but its super important to note this otherwise you can get into a broken state :)

:::

Basic authentication credentials are then required when making API requests, as in the following:

```shell
curl --request POST 'http://localhost:8080/v1/process-definitions/search' \
-u demo:demo \
--header 'Content-Type: application/json' \
--data-raw '{}'
```
23 changes: 13 additions & 10 deletions docs/self-managed/identity/what-is-identity.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,19 @@ sidebar_label: "What is Identity?"
description: "Identity is the component within the Camunda 8 stack responsible for authentication and authorization."
---

Identity is the component within the Camunda 8 stack responsible for authentication and authorization. It allows you to manage:
Identity in the Camunda 8 stack is handled by two distinct components: Identity for [Orchestration clusters](#identity-for-orchestration-clusters), and Identity for [Web Modeler and Console](#identity-for-web-modeler-and-console). In both cases, Identity is responsible for managing authentication and authorization within the Camunda 8 stack, but each implementation requires different configurations. In the case of Web Modeler and Console, Identity must be set up independently.

For more information on these differences, see the Self-Managed [reference architecture](/self-managed/reference-architecture/reference-architecture.md#orchestration-cluster-vs-web-modeler-and-console).

## Identity for Orchestration clusters

Identity is included by default in the [Orchestration cluster](/self-managed//reference-architecture/reference-architecture.md#orchestration-cluster), and does not require any external dependencies. For more information, see the Identity [configuration options](/self-managed/identity/orchestration-identity/configuration.md).

## Identity for Web Modeler and Console

For [Web Modeler and Console deployments](/self-managed/reference-architecture/reference-architecture.md#), Identity runs as a separate and dedicated component. For more information, see the guides on using an [existing Keycloak](/self-managed/setup/guides/using-existing-keycloak.md) instance, and connecting to an [OIDC provider](/self-managed/setup/guides/connect-to-an-oidc-provider.md).

Once deployed, Identity manages the following in Web Modeler and Console:

- Applications
- APIs
Expand All @@ -19,12 +31,3 @@ For example, using Identity you can:
- [Create a group](/self-managed/identity/user-guide/groups/create-group.md) to apply a set of roles and authorizations to users.
- [Manage resource authorizations](/self-managed/identity/user-guide/authorizations/managing-resource-authorizations.md) to control resource access within the Identity application.
- [Utilize configuration variables](/self-managed/identity/deployment/configuration-variables.md).

## Next steps

If you're new to Identity, we suggest reviewing our [getting started guide](./getting-started/install-identity.md).

You can use Identity for authentication with Keycloak. The following guidance can be used during platform installation and deployment:

- [Use existing Keycloak](/self-managed/setup/guides/using-existing-keycloak.md)
- [Connect to an OIDC provider](/self-managed/setup/guides/connect-to-an-oidc-provider.md)
106 changes: 58 additions & 48 deletions sidebars.js
Original file line number Diff line number Diff line change
Expand Up @@ -1368,63 +1368,73 @@ module.exports = {

Identity: [
"self-managed/identity/what-is-identity",
"self-managed/identity/getting-started/install-identity",
{
"User guide": [
{
Configuration: [
"self-managed/identity/user-guide/configuration/making-identity-production-ready",
"self-managed/identity/user-guide/configuration/configure-external-identity-provider",
"self-managed/identity/user-guide/configuration/configure-logging",
"self-managed/identity/user-guide/configuration/connect-to-an-existing-keycloak",
],
},
{
Roles: [
"self-managed/identity/user-guide/roles/add-assign-role",
"self-managed/identity/user-guide/roles/add-assign-permission",
],
},
{
Groups: [
"self-managed/identity/user-guide/groups/create-group",
"self-managed/identity/user-guide/groups/assign-users-roles-to-group",
],
},
{
Authorizations: [
"self-managed/identity/user-guide/authorizations/managing-resource-authorizations",
"self-managed/identity/user-guide/authorizations/managing-user-access",
"self-managed/identity/user-guide/authorizations/generating-m2m-tokens",
],
},
{
Tenants: [
"self-managed/identity/user-guide/tenants/managing-tenants",
],
},
"Orchestration Cluster Identity": [
"self-managed/identity/orchestration-identity/installation",
"self-managed/identity/orchestration-identity/configuration",
],
},
{
"Identity for Web Modeler and Console": [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💭 How do you feel about positioning this one as Management cluster Identity?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would love to have a simple name for this, but right now we use "Web Modeler and Console" throughout the docs. For consistency - and to make it easier to update when/if this gets changed - I'd like to have it match for now.

"self-managed/identity/getting-started/install-identity",
{
"Mapping rules": [
"self-managed/identity/user-guide/mapping-rules/managing-mapping-rules",
"User guide": [
{
Configuration: [
"self-managed/identity/user-guide/configuration/making-identity-production-ready",
"self-managed/identity/user-guide/configuration/configure-external-identity-provider",
"self-managed/identity/user-guide/configuration/configure-logging",
"self-managed/identity/user-guide/configuration/connect-to-an-existing-keycloak",
],
},
{
Roles: [
"self-managed/identity/user-guide/roles/add-assign-role",
"self-managed/identity/user-guide/roles/add-assign-permission",
],
},
{
Groups: [
"self-managed/identity/user-guide/groups/create-group",
"self-managed/identity/user-guide/groups/assign-users-roles-to-group",
],
},
{
Authorizations: [
"self-managed/identity/user-guide/authorizations/managing-resource-authorizations",
"self-managed/identity/user-guide/authorizations/managing-user-access",
"self-managed/identity/user-guide/authorizations/generating-m2m-tokens",
],
},
{
Tenants: [
"self-managed/identity/user-guide/tenants/managing-tenants",
],
},
{
"Mapping rules": [
"self-managed/identity/user-guide/mapping-rules/managing-mapping-rules",
],
},
{
"Additional features": [
"self-managed/identity/user-guide/additional-features/adding-an-api",
"self-managed/identity/user-guide/additional-features/incorporate-applications",
],
},
],
},
{
"Additional features": [
"self-managed/identity/user-guide/additional-features/adding-an-api",
"self-managed/identity/user-guide/additional-features/incorporate-applications",
Deployment: [
"self-managed/identity/deployment/configuration-variables",
"self-managed/identity/deployment/application-monitoring",
"self-managed/identity/deployment/starting-configuration-for-identity",
"self-managed/identity/deployment/resource-management",
],
},
"self-managed/identity/troubleshooting/troubleshoot-identity",
],
},
{
Deployment: [
"self-managed/identity/deployment/configuration-variables",
"self-managed/identity/deployment/application-monitoring",
"self-managed/identity/deployment/starting-configuration-for-identity",
"self-managed/identity/deployment/resource-management",
],
},
"self-managed/identity/troubleshooting/troubleshoot-identity",
],
},
{
Expand Down
Loading