Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
20 commits
Select commit Hold shift + click to select a range
104d468
feat: add blank SSO, magic link, and user provisioning pages
mintlify[bot] Sep 3, 2026
674e2d5
Add initial magic link text
gsavage Sep 3, 2026
142b9e6
docs: replace image placeholders with embeds on magic link page
mintlify[bot] Sep 3, 2026
cbd92ce
fix: correct duplicated description on magic link page
mintlify[bot] Sep 3, 2026
d19fc5f
feat: add wand-magic-sparkles icon to magic link page
mintlify[bot] Sep 3, 2026
1294096
feat: add key icon to single sign on page
mintlify[bot] Sep 3, 2026
78499d5
docs: add SSO wizard screenshots and apply review fixes
gsavage Sep 4, 2026
4c506c4
Merge remote-tracking branch 'origin/docs/auth-pages' into docs/auth-…
gsavage Sep 4, 2026
ddf8d50
fix: point magic link images at their new subdirectory
gsavage Sep 4, 2026
e43928e
Incorporate lots of Magic Link feedback from GitHub review
gsavage Sep 4, 2026
0bc0e9e
More, minor, fixes
gsavage Sep 4, 2026
67efbb4
docs: document SCIM automated user provisioning
FayeSGW Sep 4, 2026
f754db8
docs: format automated user provisioning page for consistency
mintlify[bot] Sep 4, 2026
3a6d284
docs: cross-link SCIM provisioning from sso and roles pages
FayeSGW Sep 4, 2026
8f203d8
docs: align scim role behavior across provisioning and roles pages
FayeSGW Sep 4, 2026
014387c
docs: standardize auth page naming and add sign-in cross-links
gsavage Sep 7, 2026
cbbd6dd
docs: clarify when scim needs an sso connection change
gsavage Sep 7, 2026
df5cc01
docs: add scim prerequisites
gsavage Sep 7, 2026
fb1bc00
docs: separate scim cutover from steady state
gsavage Sep 7, 2026
a373ba6
docs: restructure scim procedures as steps
gsavage Sep 7, 2026
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
31 changes: 31 additions & 0 deletions administration/authentication/magic_link.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
---
title: Magic Link
description: "Learn about signing in to Kosli with Magic Link."
icon: "wand-magic-sparkles"
---

Magic Link is a way of signing into Kosli without needing to set up [single sign-on](/administration/authentication/single_sign_on). When you want to sign in, Kosli emails you a link, and clicking that link signs you in.

## Enabling Magic Link

To use Magic Link with your company email, email [support@kosli.com](mailto:support@kosli.com) and we'll enable it for your email domain.

## Using Magic Link

<Steps>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggestion — the <Step> elements have no title, unlike every other <Steps> block in administration/. single_sign_on.md:20-44 in this same PR titles all four of its steps, and service_accounts.md:15-28 titles all four of its. Without titles these render as bare numbers, so a reader scanning the page gets no summary of the flow.

Suggested change
<Steps>
<Steps>
<Step>

The other two would be something like title="Check your inbox" and title="Click the link".

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggestion — these <Step> elements have no title, unlike every other <Steps> block in administration/. single_sign_on.md:20-44 in this same PR titles all four of its steps, and service_accounts.md:15-28 titles all four of its. Untitled steps render as bare numbers, so a reader scanning the page gets no summary of the flow — and the two pages added together are inconsistent with each other.

Suggested change
<Steps>
<Steps>
<Step>

The other two would be something like title="Check your inbox" and title="Click the link".

<Step>
Once Magic Link is enabled for your domain, enter your email address on the Kosli sign-in page and select **Continue with SSO** — the same button is used for Magic Link sign-in.

<Frame><img src="/images/administration/magic-link-enter-email.png" alt="Kosli sign-in page with an email address entered and the Continue with SSO button" /></Frame>
</Step>
<Step>
Kosli then sends you an email containing the link and asks you to check your inbox.

<Frame><img src="/images/administration/magic-link-check-email.png" alt="Kosli prompt telling you to check your inbox for the sign-in link" /></Frame>
</Step>
<Step>
The email contains a button to click; clicking this will sign you in to your Kosli account.

<Frame><img src="/images/administration/magic-link-email.png" alt="Magic Link email from Kosli with a button to sign in" /></Frame>
</Step>
</Steps>
47 changes: 47 additions & 0 deletions administration/authentication/single_sign_on.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
---
title: Single sign-on
description: "Learn about configuring single sign-on with Kosli"
icon: "key"
---
Comment thread
gsavage marked this conversation as resolved.

Kosli supports signing in using your identity provider, via single sign-on (SSO). If you don't use an identity provider, [Magic Link](/administration/authentication/magic_link) is an alternative way to sign in.

## Enabling single sign-on

When you are ready for your organization to access Kosli using single sign-on, your IT team will need to configure a new SSO connection. It's done through a self-service setup wizard to make this as straightforward as possible.

Your Kosli Customer Success representative will provide you with a custom direct link to your personalized SSO setup wizard.

## Step by step

Before you begin, you will need access to your Identity Provider (IdP) — such as Azure Entra ID, Okta, or Google Workspace — with permissions to create or modify application registrations and SSO configurations.

<Steps>
<Step title="Review current status">
Open the link provided by Kosli. The wizard will display the current state of your SSO connection. If no connection exists yet, you'll see an option to add one.

<Frame>
<img src="/images/administration/add-sso.png" alt="The SSO setup wizard welcome screen, showing an SSO Configuration card with an Add button, and grayed-out SSO Mapping and SSO Testing options under Advanced." />
</Frame>
</Step>
<Step title="Select your identity provider">
Click **+ Add**, then select your IdP from the list (for example, Okta, Azure Entra ID, Keycloak, or Auth0). Select **OIDC** if there is a choice. The exception is Okta: its SCIM integration only works with a SAML connection, so select **SAML** if you use Okta and expect to add [SCIM provisioning](/administration/managing_users/automated_user_provisioning) — choosing OIDC now means recreating the connection later.

<Frame>
<img src="/images/administration/select-idp.png" alt="The Identity Provider (IdP) Selection step of the wizard, with a search box and cards for OKTA, Azure Entra ID, Keycloak, and Auth0." />
</Frame>
</Step>
<Step title="Configure the connection">
The wizard will guide you through the setup process with screenshots specific to your IdP. You'll be asked to copy and paste values between your IdP and the wizard, including:

- **Client ID** from your IdP's application registration
- **Client Secret** from your IdP's application registration

<Frame>
<img src="/images/administration/sso-setup-suite.png" alt="Step 2 of 6 of the wizard, Identity Provider Information and User Attribute Mapping, with Client ID and Client Secret fields and a screenshot showing where to find those values in Okta." />
</Frame>
</Step>
<Step title="Notify Kosli">
Once you have completed the SSO configuration in the wizard, please let your Kosli Customer Success representative know. We will then switch your email domain to use SSO and confirm when the migration is complete.
</Step>
</Steps>
110 changes: 110 additions & 0 deletions administration/managing_users/automated_user_provisioning.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,110 @@
---
title: Automated user provisioning
description: "Learn about configuring automated user provisioning (SCIM) with Kosli."
---
Comment thread
FayeSGW marked this conversation as resolved.
Comment thread
gsavage marked this conversation as resolved.

Kosli supports SCIM provisioning and deprovisioning of users. This feature allows users to be added to Kosli by assigning them to the Kosli application within your Identity Provider (IdP). This page explains how to get started.

## Benefits

User provisioning within your IdP simplifies the process of granting access to Kosli; you no longer need to explicitly invite people one-by-one. Your existing processes and procedures for onboarding team members can now be leveraged to give access to the Kosli platform.

User deprovisioning within your IdP means that when your people no longer need access to Kosli, for example because they have changed roles or left your organization, their access to Kosli is revoked automatically.

## Prerequisites

Before configuring SCIM, make sure that:

- **[Single sign-on](/administration/authentication/single_sign_on) is already configured.** SCIM builds on your
existing SSO connection, and IdP groups are mapped to Kosli roles in the SSO part of the same wizard.
- **SCIM is enabled for your Kosli organizations.** Tell your Kosli Customer Success representative which
organizations you want SCIM for, so that the matching roles can be created — see
[Roles for new and existing users](#roles-for-new-and-existing-users) below.
- **You have a link to the setup wizard.** Your Customer Success representative provides one with instructions
for your IdP, which you can pass on to the team that will do the work.
- **That team can administer your IdP.** They need permissions to create or modify application registrations,
and to manage the groups you map to Kosli roles.

## Setup

The team that manages your IdP configures the connection between your IdP and Kosli's auth provider. Because
different IdPs need different configuration, the wizard gives step-by-step instructions specific to yours.

<Note>
Adding SCIM does not normally require any change to your existing SSO connection. The exception is Okta over
OIDC: Okta's SCIM integration only works with a SAML connection, so an Okta OIDC connection has to be recreated
using SAML before SCIM can be enabled. If you are not sure which your IdP uses, ask your Kosli Customer Success
representative.
</Note>

<Steps>
<Step title="Open the wizard and select SCIM Configuration">
Open the link from your Customer Success representative and select the **SCIM Configuration** box on the
first screen.

<Frame>
<img src="/images/administration/scim-setup-wizard.png" alt="Start page for the SSO and SCIM setup suite wizard" />
</Frame>
</Step>
<Step title="Follow the wizard">
The wizard then guides you through setting up and configuring the application, with screenshots at each
stage.
</Step>
<Step title="Create your IdP groups and add your users">
Create a group in your IdP for each Kosli organization and role you need, then add your users to them. See
[Roles for new and existing users](#roles-for-new-and-existing-users) for the group naming scheme, and for
how to map those groups to Kosli roles.
</Step>
<Step title="Trigger a provisioning cycle">

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Improvement — the Setup sequence ends by triggering a sync, but the mapping that makes the sync produce correct roles isn't a step in it.

### Map your IdP groups to Kosli roles (line 88) is a required, three-step procedure in a different wizard, and it sits 26 lines below this block under a section titled "Roles for new and existing users" — which reads as conceptual, not procedural. Step 3 links there for "how to map those groups to Kosli roles", but a reader working this <Steps> block top-to-bottom reaches "Trigger a provisioning cycle" without having saved any mapping.

That matters more here than in most procedures, because the page itself says the first sync is not reversible in the app: it "provisions every assigned user at once" (line 76) and afterwards "their roles can no longer be changed in Kosli" (line 108).

Either pull the group-mapping steps into this sequence before the trigger step, or make the dependency explicit here:

Suggested change
<Step title="Trigger a provisioning cycle">
<Step>
Before triggering a sync, map each IdP group to its Kosli role — see
[Map your IdP groups to Kosli roles](#map-your-idp-groups-to-kosli-roles). Users provisioned before the
mapping is saved will not get the roles you intend.
</Step>
<Step>

Fix this →

Once your users are in the right groups and you have triggered a provisioning cycle, changes to your users
within the IdP are reflected in Kosli.
</Step>
</Steps>

## Timeliness

Once changes within your IdP have been synced, they are typically reflected in Kosli within five minutes.

## Existing Kosli users

People who already have access to Kosli via SSO keep that access. Enabling SCIM does not, by itself, change
anyone's roles or organization memberships — nothing in Kosli moves until your IdP sends a change.

From then on, your IdP drives membership. Once a user has been provisioned through SCIM, the groups they belong
to in your IdP determine their organizations and roles in Kosli, replacing whatever they had before.

That makes the first sync worth planning. A full or forced sync in your IdP — however it is labeled there —
provisions every assigned user at once, not only the ones you have just changed, so make sure your groups and
[role mappings](#map-your-idp-groups-to-kosli-roles) are correct before you trigger one.

## Roles for new and existing users

Kosli supports role assignment through your IdP, so that users' [roles within Kosli](/administration/managing_users/roles_in_kosli) can be managed by your onboarding and IT teams, without requiring admin access to Kosli.

You will need to tell us which of your Kosli organizations you wish to have SCIM enabled for; we will then create the necessary roles within our auth provider. Each organization will have four roles, with the names `kosli-<org-name>-<role>`, to correspond to the available roles in Kosli (admin, member, snapshotter, reader).

Within your IdP you will need to create a group for each of these roles. You will then add your users to the groups corresponding to the organizations/roles you wish them to have in Kosli. If a member receives two different roles for the same organization, the highest-privilege role will be assigned.
Comment on lines +80 to +86

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggestion — this section restates two things the reader has already been given, and names the auth provider two different ways.

  • Line 84 "tell us which of your Kosli organizations you wish to have SCIM enabled for" is the same instruction as the prerequisite at lines 20-22 — and that prerequisite links here for the detail, so the reader follows a pointer and lands on the same sentence they came from.
  • Line 86 "create a group for each of these roles… add your users to the groups" is the same instruction as Setup step 3 (lines 53-57), which also links here.
  • Line 30 says "Kosli's auth provider"; line 84 says "our auth provider" for the same thing. The rest of these pages use "Kosli" rather than first person (single_sign_on.md:45 "your Kosli Customer Success representative").

Keeping only the naming scheme and the precedence rule here — the two facts that appear nowhere else — removes the round trip:

Suggested change
## Roles for new and existing users
Kosli supports role assignment through your IdP, so that users' [roles within Kosli](/administration/managing_users/roles_in_kosli) can be managed by your onboarding and IT teams, without requiring admin access to Kosli.
You will need to tell us which of your Kosli organizations you wish to have SCIM enabled for; we will then create the necessary roles within our auth provider. Each organization will have four roles, with the names `kosli-<org-name>-<role>`, to correspond to the available roles in Kosli (admin, member, snapshotter, reader).
Within your IdP you will need to create a group for each of these roles. You will then add your users to the groups corresponding to the organizations/roles you wish them to have in Kosli. If a member receives two different roles for the same organization, the highest-privilege role will be assigned.
## Roles for new and existing users
Kosli supports role assignment through your IdP, so that users' [roles within Kosli](/administration/managing_users/roles_in_kosli) can be managed by your onboarding and IT teams, without requiring admin access to Kosli.
Kosli creates four roles per organization in its auth provider, named `kosli-<org-name>-<role>` — one for each Kosli role (admin, member, snapshotter, reader). Create a group in your IdP for each one you need.
If a user ends up with two different roles for the same organization, the highest-privilege role wins.


### Map your IdP groups to Kosli roles

<Steps>
<Step title="Switch to the SSO Configuration wizard">
Group mapping is done in **SSO Configuration**, not in the SCIM configuration you used to set up
provisioning. Open **SSO Configuration** and go to the **Group Attribute Mapping** tab.
</Step>
<Step title="Map each group to its Kosli role">
Follow the instructions on the tab, mapping each of your IdP groups to the corresponding role.

<Frame>
<img src="/images/administration/scim-group-role-mapping.png" alt="Section in the SSO Setup Suite Wizard showing how to configure mapping of IdP groups to Kosli roles" />
</Frame>
</Step>
<Step title="Save the configuration">
Click through to the **Testing** page and save the configuration.
</Step>
</Steps>

<Note>
Once a user has been provisioned through SCIM, your IdP is authoritative for that user: their roles can no
longer be changed in Kosli, so every later role change has to be made through their IdP group membership.
</Note>
4 changes: 4 additions & 0 deletions administration/managing_users/roles_in_kosli.md
Original file line number Diff line number Diff line change
Expand Up @@ -188,6 +188,10 @@ The following sections provide more details about each Kosli user role, includin

## Assigning roles

<Note>
This procedure does not apply to users provisioned through [automated user provisioning](/administration/managing_users/automated_user_provisioning) — their roles cannot be changed in Kosli. Manage those roles through your identity provider groups instead.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Improvement — on this page, "users" is defined to include service accounts, which makes this note say something you don't mean.

roles_in_kosli.md:8 sets a page-wide convention: "Wherever this page mentions a 'user', read it as 'user or service account' unless explicitly stated otherwise." Read under that rule, this note tells an admin that service-account roles also can't be changed in Kosli once SCIM is on — and service accounts are never SCIM-provisioned, so the dropdown procedure below still applies to them in full.

For an admin who has just enabled SCIM and needs to change a CI service account's role, that's the difference between doing it in one minute and opening a support ticket. Say "people" explicitly, since the note is user-only:

Suggested change
This procedure does not apply to users provisioned through [automated user provisioning](/administration/managing_users/automated_user_provisioning) — their roles cannot be changed in Kosli. Manage those roles through your identity provider groups instead.
<Note>
This procedure does not apply to people provisioned through [automated user provisioning](/administration/managing_users/automated_user_provisioning) — their roles cannot be changed in Kosli, so manage them through your identity provider groups instead. Service accounts are never provisioned this way, so their roles are always changed here.
</Note>

Fix this →

</Note>

To assign or change a user's role:

1. Log in to Kosli as an Admin
Expand Down
7 changes: 5 additions & 2 deletions config/navigation.json
Original file line number Diff line number Diff line change
Expand Up @@ -47,14 +47,17 @@
"pages": [
"administration/authentication/api_authentication_methods",
"administration/authentication/service_accounts",
"administration/authentication/api_key_rotation"
"administration/authentication/api_key_rotation",
"administration/authentication/single_sign_on",
"administration/authentication/magic_link"
]
Comment thread
gsavage marked this conversation as resolved.
},
{
"group": "Users & roles",
"pages": [
"administration/managing_users/roles_in_kosli",
"administration/managing_users/mapping_users_to_roles"
"administration/managing_users/mapping_users_to_roles",
"administration/managing_users/automated_user_provisioning"
]
},
Comment on lines 48 to 62

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggestion — the SSO/SCIM procedure is split across two groups, and the human sign-in pages are last in a group that now opens with machine credentials.

All three pages are correctly listed (core rule 2 satisfied), but the grouping splits one job across two sidebar groups. automated_user_provisioning.md requires an SSO connection as a prerequisite (line 18), and its group-mapping steps are performed in the SSO Configuration wizard (line 91) — so an admin doing SCIM works in Users & roles and Authentication & access alternately. Its Diátaxis form is also a how-to about IdP configuration, like single_sign_on.md, not role reference like its two current siblings.

Leading with human sign-in also matters now that there are five entries: an admin arriving at "Authentication & access" meets three API-credential pages before the two pages about how people log in.

Suggested change
"administration/authentication/api_authentication_methods",
"administration/authentication/service_accounts",
"administration/authentication/api_key_rotation"
"administration/authentication/api_key_rotation",
"administration/authentication/single_sign_on",
"administration/authentication/magic_link"
]
},
{
"group": "Users & roles",
"pages": [
"administration/managing_users/roles_in_kosli",
"administration/managing_users/mapping_users_to_roles"
"administration/managing_users/mapping_users_to_roles",
"administration/managing_users/automated_user_provisioning"
]
},
"pages": [
"administration/authentication/single_sign_on",
"administration/authentication/magic_link",
"administration/managing_users/automated_user_provisioning",
"administration/authentication/api_authentication_methods",
"administration/authentication/service_accounts",
"administration/authentication/api_key_rotation"
]
},
{
"group": "Users & roles",
"pages": [
"administration/managing_users/roles_in_kosli",
"administration/managing_users/mapping_users_to_roles"
]
},

Non-blocking, and the file path can stay under managing_users/ either way — but if you'd rather not move it, at least the two sign-in pages are worth promoting above the API pages.

{
Expand Down
4 changes: 4 additions & 0 deletions getting_started/authenticating_to_kosli.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,8 @@ For anything automated, use a service account. Personal API keys inherit your us

- EU: [app.kosli.com](https://app.kosli.com)
- US: [app.us.kosli.com](https://app.us.kosli.com)

Depending on how your organization is set up, you'll sign in with [single sign-on](/administration/authentication/single_sign_on) or [Magic Link](/administration/authentication/magic_link).
</Step>
<Step title="Create a key">
- **For CI/CD**, follow [Service accounts](/administration/authentication/service_accounts) to create a service account and generate its first API key.
Expand All @@ -48,6 +50,8 @@ For CLI usage, basic auth, and full examples, see [API authentication methods](/

## See also

- [Single sign-on](/administration/authentication/single_sign_on) — configure sign-in through your identity provider.
- [Magic Link](/administration/authentication/magic_link) — sign in with an emailed link, without an identity provider.
- [Service accounts](/administration/authentication/service_accounts) — admin lifecycle for machine credentials.
- [API key rotation](/administration/authentication/api_key_rotation) — how rotation works, with a [step-by-step tutorial](/tutorials/rotating_api_keys).
- [Roles in Kosli](/administration/managing_users/roles_in_kosli) — what users and service accounts can do at each role.
Binary file added images/administration/add-sso.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added images/administration/magic-link-email.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added images/administration/scim-setup-wizard.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added images/administration/select-idp.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added images/administration/sso-setup-suite.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.