This is what an AI/RAG pipeline sees when it indexes this page — the same output served at https://camelmind-docs.vercel.app/api/llms/features/auth-rbac.Back to doc

Rendered doc

Authentication & RBAC

Configure authentication and role-based access control (RBAC) to protect documentation pages and control access by user role.

CamelMind includes built-in support for authentication and role-based access control (RBAC).

Authentication identifies who a user is, while RBAC determines which documentation pages they are allowed to access.

Authentication is disabled by default, so a new CamelMind site is public until you enable authentication.


Choose an authentication mode with enabled and requireLogin

CamelMind determines the authentication mode from the auth.enabled and auth.requireLogin settings.

enabledrequireLoginBehavior
false—Public. Anyone can access every page.
truefalsePartial login. Public pages remain accessible, but users can sign in to access protected pages.
truetrueRequired login. Users must sign in to access pages unless you list the page in publicPaths.

Protected documentation pages automatically restrict related features, such as viewing the page or downloading its Markdown source.

Offline and PDF downloads follow your site's authentication settings automatically. When you enable authentication, only authenticated users can download these artifacts. When you disable authentication, any user can publicly access the downloads.


How to enable authentication in camelmind.config.ts

Enable authentication by setting auth.enabled: true in camelmind.config.ts. Set auth.requireLogin: true when users must sign in to access protected documentation pages.

typescript
auth: {
  enabled: true,
  requireLogin: true,
  provider: "oidc",

  oidc: {
    issuer: process.env.OIDC_ISSUER ?? "",
    clientId: process.env.OIDC_CLIENT_ID ?? "",
    clientSecret: process.env.OIDC_CLIENT_SECRET ?? "",
    rolesClaim: "realm_access.roles",
    roleMapping: {},
  },

  publicPaths: [
    "/",
    "/home",
    "/login",
    "/api/auth",
  ],
}

You supply most authentication settings through environment variables.

bash
CAMELMIND_AUTH_ENABLED=true
CAMELMIND_AUTH_REQUIRE_LOGIN=true
CAMELMIND_AUTH_PROVIDER=oidc

OIDC_ISSUER=https://keycloak.example.com/realms/my-realm
OIDC_CLIENT_ID=my-docs
OIDC_CLIENT_SECRET=super-secret

SESSION_SECRET=your-random-session-secret

How to configure an OIDC identity provider

Configure an OpenID Connect (OIDC) identity provider to authenticate CamelMind users.

CamelMind works with any OIDC-compatible identity provider, including:

  • Auth0
  • Okta
  • Microsoft Entra ID (Azure AD)
  • Amazon Cognito
  • Any standards-compliant OIDC provider

Configure your identity provider to:

  1. Register CamelMind as an application.
  2. Set the redirect URI to:
text
[https://your-site.example.com/api/auth/callback](https://your-site.example.com/api/auth/callback)
  1. Include user roles in the ID token or access token.

CamelMind reads user roles from the token claim specified by rolesClaim.


How to configure rolesClaim for provider roles

Set rolesClaim to the token claim that contains the user's roles. CamelMind reads roles from this claim before applying roleMapping.

For example, Keycloak stores realm roles in:

typescript
rolesClaim: "realm_access.roles"

The complete OIDC configuration can look like this:

typescript
oidc: {
  issuer: process.env.OIDC_ISSUER ?? "",
  clientId: process.env.OIDC_CLIENT_ID ?? "",
  clientSecret: process.env.OIDC_CLIENT_SECRET ?? "",
  rolesClaim: "realm_access.roles",
  roleMapping: {},
}

How to map identity provider roles with roleMapping

Use roleMapping to translate role names from your identity provider into the CamelMind role names used in nav.yml.

For example, if your identity provider provides Realm_Admin and Realm_Vendor roles, map them to the CamelMind roles admin and vendor:

typescript
roleMapping: {
  "Realm_Admin": "admin",
  "Realm_Vendor": "vendor",
}

The mapping works from the identity provider's role name to the CamelMind role name:

Identity provider roleCamelMind role
Realm_Adminadmin
Realm_Vendorvendor

CamelMind uses the mapped role names when evaluating the roles values defined in nav.yml.


How to restrict documentation pages with roles

Use the roles field in nav.yml to specify which CamelMind roles can access a documentation page.

yaml
- label: Admin Dashboard
  slug: /admin/dashboard
  file: content/admin/dashboard.mdx
  roles: [admin]

- label: Vendor Portal
  slug: /vendor
  file: content/vendor.mdx
  roles: [vendor]

- label: Getting Started
  slug: /getting-started
  file: content/getting-started.mdx
  roles: []

CamelMind compares the roles assigned to the authenticated user with the roles defined for each page.

rolesAccess
[]Public page
["admin"]Users with the admin role
["vendor","admin"]Users with either the vendor or admin role

Disabling authentication treats every page as public, even if you configure the roles setting.


How CamelMind enforces authentication and RBAC access

CamelMind enforces documentation access in two ways: navigation filtering and route protection.

CamelMind automatically hides pages from the navigation when the current user does not have the required role.


How to allow unauthenticated access with publicPaths

You can use publicPaths to keep specific paths accessible without signing in when you enable requireLogin.

typescript
publicPaths: [
  "/",
  "/home",
  "/login",
  "/api/auth",
]

Common public paths include:

  • Home pages
  • Login pages
  • Marketing pages
  • Authentication endpoints

When you enable requireLogin, users can still access any pages listed in publicPaths without authenticating.


How to test authentication locally with dev-mock

Use the built-in dev-mock authentication provider to test authentication and RBAC locally without configuring an external identity provider.

typescript
auth: {
  enabled: true,
  requireLogin: false,
  provider: "dev-mock",
}

The mock provider simulates a signed-in user so you can test navigation, protected pages, and role-based access during local development.

Warning

Never deploy with provider: "dev-mock". It bypasses real authentication and is intended for local development only.

What the AI sees

1> For a complete documentation index, see /llms.txt. To read any public page as Markdown, append .md to the URL.
2 
3CamelMind includes built-in support for authentication and role-based access control (RBAC).
4 
5Authentication identifies who a user is, while RBAC determines which documentation pages they are allowed to access.
6 
7Authentication is **disabled by default**, so a new CamelMind site is public until you enable authentication.
8 
9---
10 
11## Choose an authentication mode with enabled and requireLogin
12 
13CamelMind determines the authentication mode from the `auth.enabled` and `auth.requireLogin` settings.
14 
15| `enabled` | `requireLogin` | Behavior |
16| --- | --- | --- |
17| `false` | — | Public. Anyone can access every page. |
18| `true` | `false` | Partial login. Public pages remain accessible, but users can sign in to access protected pages. |
19| `true` | `true` | Required login. Users must sign in to access pages unless you list the page in `publicPaths`. |
20 
21Protected documentation pages automatically restrict related features, such as viewing the page or downloading its Markdown source.
22 
23Offline and PDF downloads follow your site's authentication settings automatically. When you enable authentication, only authenticated users can download these artifacts. When you disable authentication, any user can publicly access the downloads.
24 
25---
26 
27## How to enable authentication in camelmind.config.ts
28 
29Enable authentication by setting `auth.enabled: true` in `camelmind.config.ts`. Set `auth.requireLogin: true` when users must sign in to access protected documentation pages.
30 
31```typescript
32auth: {
33 enabled: true,
34 requireLogin: true,
35 provider: "oidc",
36 
37 oidc: {
38 issuer: process.env.OIDC_ISSUER ?? "",
39 clientId: process.env.OIDC_CLIENT_ID ?? "",
40 clientSecret: process.env.OIDC_CLIENT_SECRET ?? "",
41 rolesClaim: "realm_access.roles",
42 roleMapping: {},
43 },
44 
45 publicPaths: [
46 "/",
47 "/home",
48 "/login",
49 "/api/auth",
50 ],
51}
52```
53 
54You supply most authentication settings through environment variables.
55 
56```bash
57CAMELMIND_AUTH_ENABLED=true
58CAMELMIND_AUTH_REQUIRE_LOGIN=true
59CAMELMIND_AUTH_PROVIDER=oidc
60 
61OIDC_ISSUER=https://keycloak.example.com/realms/my-realm
62OIDC_CLIENT_ID=my-docs
63OIDC_CLIENT_SECRET=super-secret
64 
65SESSION_SECRET=your-random-session-secret
66```
67---
68 
69## How to configure an OIDC identity provider
70 
71Configure an OpenID Connect (OIDC) identity provider to authenticate CamelMind users.
72 
73CamelMind works with any OIDC-compatible identity provider, including:
74 
75- Auth0
76- Okta
77- Microsoft Entra ID (Azure AD)
78- Amazon Cognito
79- Any standards-compliant OIDC provider
80 
81Configure your identity provider to:
82 
831. Register CamelMind as an application.
842. Set the redirect URI to:
85 
86```text
87[https://your-site.example.com/api/auth/callback](https://your-site.example.com/api/auth/callback)
88```
89 
903. Include user roles in the ID token or access token.
91 
92CamelMind reads user roles from the token claim specified by `rolesClaim`.
93 
94---
95 
96## How to configure rolesClaim for provider roles
97 
98Set `rolesClaim` to the token claim that contains the user's roles. CamelMind reads roles from this claim before applying `roleMapping`.
99 
100For example, Keycloak stores realm roles in:
101 
102```typescript
103rolesClaim: "realm_access.roles"
104```
105 
106The complete OIDC configuration can look like this:
107 
108```typescript
109oidc: {
110 issuer: process.env.OIDC_ISSUER ?? "",
111 clientId: process.env.OIDC_CLIENT_ID ?? "",
112 clientSecret: process.env.OIDC_CLIENT_SECRET ?? "",
113 rolesClaim: "realm_access.roles",
114 roleMapping: {},
115}
116```
117---
118 
119## How to map identity provider roles with roleMapping
120 
121Use `roleMapping` to translate role names from your identity provider into the CamelMind role names used in `nav.yml`.
122 
123For example, if your identity provider provides `Realm_Admin` and `Realm_Vendor` roles, map them to the CamelMind roles `admin` and `vendor`:
124 
125```typescript
126roleMapping: {
127 "Realm_Admin": "admin",
128 "Realm_Vendor": "vendor",
129}
130```
131 
132The mapping works from the identity provider's role name to the CamelMind role name:
133 
134| Identity provider role | CamelMind role |
135| --- | --- |
136| `Realm_Admin` | `admin` |
137| `Realm_Vendor` | `vendor` |
138 
139CamelMind uses the mapped role names when evaluating the `roles` values defined in `nav.yml`.
140 
141---
142 
143## How to restrict documentation pages with roles
144 
145Use the `roles` field in `nav.yml` to specify which CamelMind roles can access a documentation page.
146 
147```yaml
148- label: Admin Dashboard
149 slug: /admin/dashboard
150 file: content/admin/dashboard.mdx
151 roles: [admin]
152 
153- label: Vendor Portal
154 slug: /vendor
155 file: content/vendor.mdx
156 roles: [vendor]
157 
158- label: Getting Started
159 slug: /getting-started
160 file: content/getting-started.mdx
161 roles: []
162```
163 
164CamelMind compares the roles assigned to the authenticated user with the roles defined for each page.
165 
166| `roles` | Access |
167| --- | --- |
168| `[]` | Public page |
169| `["admin"]` | Users with the `admin` role |
170| `["vendor","admin"]` | Users with either the `vendor` or `admin` role |
171 
172Disabling authentication treats every page as public, even if you configure the roles setting.
173 
174---
175 
176## How CamelMind enforces authentication and RBAC access
177 
178CamelMind enforces documentation access in two ways: navigation filtering and route protection.
179 
180=== "Navigation filtering"
181 
182CamelMind automatically hides pages from the navigation when the current user does not have the required role.
183 
184=== "Route protection"
185 
186CamelMind checks the user's permissions before rendering a protected page. Knowing the page URL does not bypass the required role.
187 
188<Callout type="important">
189Hiding a page from the navigation is not the security mechanism. CamelMind also validates permissions before rendering the page.
190</Callout>
191 
192===
193 
194---
195 
196## How to allow unauthenticated access with publicPaths
197 
198You can use `publicPaths` to keep specific paths accessible without signing in when you enable requireLogin.
199 
200```typescript
201publicPaths: [
202 "/",
203 "/home",
204 "/login",
205 "/api/auth",
206]
207```
208 
209Common public paths include:
210 
211- Home pages
212- Login pages
213- Marketing pages
214- Authentication endpoints
215 
216When you enable `requireLogin`, users can still access any pages listed in `publicPaths` without authenticating.
217 
218---
219 
220## How to test authentication locally with dev-mock
221 
222Use the built-in `dev-mock` authentication provider to test authentication and RBAC locally without configuring an external identity provider.
223 
224```typescript
225auth: {
226 enabled: true,
227 requireLogin: false,
228 provider: "dev-mock",
229}
230```
231 
232The mock provider simulates a signed-in user so you can test navigation, protected pages, and role-based access during local development.
233 
234<Callout type="warning">
235Never deploy with `provider: "dev-mock"`. It bypasses real authentication and is intended for local development only.
236</Callout>

Issues (0)

No AI-friendliness issues found.