-
Notifications
You must be signed in to change notification settings - Fork 609
Enhance SAML configuration instructions for Mattermost #8914
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
base: master
Are you sure you want to change the base?
Changes from 9 commits
d340aa0
83d5fed
201af0c
a09e76c
252f318
8010315
ee1196f
40d6d50
d2b8e2b
7f0d3f8
99c7757
9c215f5
93e4446
64ba8a1
26cdcb7
35dc2c3
f772802
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -20,34 +20,101 @@ Prerequisites | |||||
| * A Microsoft Entra tenant containing applicable user data. | ||||||
| * A verified custom domain for your tenant. See Microsoft's `Add your custom domain name to your tenant <https://learn.microsoft.com/en-us/entra/fundamentals/add-custom-domain>`__ documentation for details. | ||||||
| * A Microsoft Entra ID P1 or P2 license. | ||||||
| * An account with at least the **Application Administrator** role in your Entra tenant. | ||||||
|
|
||||||
| Set up an enterprise app for Mattermost SSO in Entra ID | ||||||
| -------------------------------------------------------- | ||||||
|
|
||||||
| 1. Log into the Microsoft Azure portal and select the **Microsoft Entra ID** service. | ||||||
| 2. In the left menu, select **Manage > Enterprise applications**. | ||||||
| 3. Select the **New application** button. | ||||||
| 4. In the **Search application** field, search for **Microsoft Entra SAML Toolkit** and select **Microsoft Entra SAML Toolkit**. | ||||||
| 5. In the **Name** field, enter **Mattermost SAML** then select the **Create** button. | ||||||
| 6. In the **Mattermost SAML** enterprise application settings, select **Manage > Users and Groups** to assign users and/or groups to the application **or** select **Manage > Properties** then set **Assignment required?** to **No** then select **Save**. | ||||||
| 7. In the **Mattermost SAML** enterprise application settings, select **Manage > Single sign-on** then select **SAML** under **Select a single sign-on method**. | ||||||
| 8. Select **Edit** in the **Basic SAML Configuration section** then set the below fields then select **Save**: | ||||||
| 1. Sign in to the `Microsoft Entra admin center <https://entra.microsoft.com>`__ with an account that has at least the **Application Administrator** role. | ||||||
| 2. In the left navigation menu, select **Entra ID > Enterprise applications**. | ||||||
| 3. Select **+ New application**. | ||||||
| 4. Select **+ Create your own application**. | ||||||
| 5. In the **What's the name of your app?** field, enter **Mattermost**. | ||||||
| 6. Under **What are you looking to do with your application?**, select **Integrate any other application you don't find in the gallery (Non-gallery)**. | ||||||
| 7. Select **Create**. Entra provisions the application; this may take a few seconds. | ||||||
| 8. In the **Mattermost** enterprise application settings, select **Manage > Users and groups** to assign users and/or groups to the application, **or** select **Manage > Properties**, set **Assignment required?** to **No**, then select **Save**. | ||||||
| 9. In the **Mattermost** enterprise application settings, select **Manage > Single sign-on**, then select **SAML** under **Select a single sign-on method**. | ||||||
| 10. Select **Edit** in the **Basic SAML Configuration** section, then set the fields below and select **Save**: | ||||||
|
|
||||||
| - **Identity (Entity ID)**: ``https://<your-mattermost-url>`` | ||||||
| - **Reply URL (Assertion Consumer Service URL)**: ``https://<your-mattermost-url>/login/sso/saml`` | ||||||
| - **Sign on URL**: ``https://<your-mattermost-url>/login`` | ||||||
| - **Identifier (Entity ID)**: ``https://<your-mattermost-url>`` | ||||||
| - **Reply URL (Assertion Consumer Service URL)**: ``https://<your-mattermost-url>/login/sso/saml`` | ||||||
| - **Sign on URL**: ``https://<your-mattermost-url>/login`` | ||||||
|
|
||||||
| 9. Select **Edit** in the **Attributes & Claims** section then set the below attributes: | ||||||
| 11. Select **Edit** in the **Attributes & Claims** section, then configure the required claim and additional claims as described below. | ||||||
|
|
||||||
| a. Set the the **Unique User Identifier (Name ID)** required claim **Name identifier format** and **Source attribute** values as required for your environment. Setting the **Source attribute** to an immutable value such as ``user.objectid`` is recommended. | ||||||
| b. Edit claim names and namespaces under **Additional claims** to match SAML attribute settings you wish to set in Mattermost. Configurable settings are Email, Username, Id, Guest, Admin, First Name, Last Name, Nickname, Position, and Preferred Language. | ||||||
| **How Entra claims map to Mattermost** | ||||||
|
|
||||||
| 10. Select **Edit** in the **SAML Certificates** section. Select **Sign SAML response and assertion** for **Signing Option** and **SHA-256** for **Signing Algorithm** then select **Save**. | ||||||
| 11. Select the **Certificate (Base64)** Download link in the **SAML Certificates** section. This is the **Identity Provider Public Certificate** to be uploaded to Mattermost. | ||||||
| 12. In the **Mattermost SAML** enterprise application settings, select **Security > Token encryption**. Select **Import Certificate** to import the Service Provider certificate. If you used the Bash script referenced in the **Before you begin** section, this is the ``mattermost-x509.crt`` file. The Import dialog says to upload a certificate with a file extension ``.cer``, but ``.crt`` files are also accepted. Upload the file then select **Add**. | ||||||
| 13. Select the ``...`` to the right of the imported certificate details, select **Activate token encryption certificate**, then select **Yes** to activate. | ||||||
| 14. On the **Home** page for **Microsoft Entra ID**, select the **Overview** link in the left navigation menu and copy the **Tenant ID** value. The **Tenant ID** will be used in Mattermost **SAML 2.0** URL settings. | ||||||
| 15. In the left navigation menu, select **Manage > Enterprise applications**. Select the **Mattermost SAML** application then copy the **Application ID**. The **Application ID** will be used in the **Identity Provider Metadata URL** setting in the Mattermost **SAML 2.0** settings. | ||||||
| The SAML assertion Entra sends to Mattermost contains a set of *claims* — name/value pairs describing the user. Mattermost reads these claims based on the attribute names you configure in **System Console > Authentication > SAML 2.0 > Attributes** (for example, **Email Attribute**, **Username Attribute**, **First Name Attribute**). | ||||||
|
|
||||||
| The **Claim name** you set in Entra must match the value you enter in the corresponding Mattermost attribute field exactly, character for character. The **Value** (also called **Source attribute**) tells Entra which user property to send — for example, ``user.mail`` sends the user's email address. | ||||||
|
|
||||||
| a. **Required claim — Unique User Identifier (Name ID)** | ||||||
|
|
||||||
| Set the **Name identifier format** and **Source attribute** values as required for your environment. Setting the **Source attribute** to an immutable value such as ``user.objectid`` is recommended, because unlike email addresses or usernames, the object ID never changes even if the user is renamed. ``user.userprincipalname`` is also a common choice when a human-readable identifier is preferred, with the trade-off that renames in Entra can orphan the corresponding Mattermost account. Mattermost uses the Name ID as the user's unique identifier by default, so you do not need to add a separate ``Id`` claim under **Additional claims**. | ||||||
|
svelle marked this conversation as resolved.
Outdated
|
||||||
|
|
||||||
| b. **Additional claims** | ||||||
|
|
||||||
| By default, Entra populates this section with four claims using the ``http://schemas.xmlsoap.org/ws/2005/05/identity/claims/...`` namespace. These work, but we recommend replacing them with short, readable names that match the attribute fields in Mattermost. To edit a claim, select it, update the **Name** field (and clear the **Namespace** field), then save. | ||||||
|
|
||||||
| The following claim configuration covers a typical Mattermost setup: | ||||||
|
|
||||||
| .. list-table:: | ||||||
| :header-rows: 1 | ||||||
| :widths: 30 25 45 | ||||||
|
|
||||||
| * - Mattermost attribute field | ||||||
| - Entra claim name | ||||||
| - Entra source attribute | ||||||
| * - Id Attribute | ||||||
| - *(leave blank)* | ||||||
| - ``user.objectid`` (via Name ID) | ||||||
|
svelle marked this conversation as resolved.
Outdated
|
||||||
| * - Email Attribute | ||||||
| - ``email`` | ||||||
| - ``user.mail`` | ||||||
| * - Username Attribute | ||||||
| - ``username`` | ||||||
| - ``user.mailnickname`` | ||||||
| * - First Name Attribute | ||||||
| - ``firstname`` | ||||||
| - ``user.givenname`` | ||||||
| * - Last Name Attribute | ||||||
| - ``lastname`` | ||||||
| - ``user.surname`` | ||||||
| * - Position Attribute | ||||||
| - ``role`` | ||||||
|
svelle marked this conversation as resolved.
Outdated
|
||||||
| - ``user.jobtitle`` | ||||||
|
|
||||||
| .. note:: | ||||||
| Use ``user.mailnickname`` rather than ``user.userprincipalname`` as the source for the username claim. The user principal name is typically formatted as an email address (``user@domain.com``), but Mattermost usernames cannot contain the ``@`` character, so SAML logins using ``user.userprincipalname`` will fail. The mail nickname is the local part of the email address (the portion before ``@``) and maps cleanly to a valid Mattermost username. | ||||||
|
||||||
| Use ``user.mailnickname`` rather than ``user.userprincipalname`` as the source for the username claim. The user principal name is typically formatted as an email address (``user@domain.com``), but Mattermost usernames cannot contain the ``@`` character, so SAML logins using ``user.userprincipalname`` will fail. The mail nickname is the local part of the email address (the portion before ``@``) and maps cleanly to a valid Mattermost username. | |
| Use ``user.mailnickname`` rather than ``user.userprincipalname`` as the source for the username claim. The user principal name is typically formatted as an email address (``user@domain.com``), but Mattermost usernames can contain only letters, numbers, and ``.``, ``-``, or ``_`` characters, so SAML logins using ``user.userprincipalname`` will fail. The mail nickname is the local part of the email address (the portion before ``@``) and maps cleanly to a valid Mattermost username. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use a warning admonition for the username-claim failure case.
This block describes a likely misconfiguration that causes SAML login failure. It should be .. warning:: rather than .. note::.
Suggested minimal diff
- .. note::
+ .. warning::As per coding guidelines: “Use warning admonition for meaningful risk such as broken behavior … or likely user/admin mistakes with negative consequences.”
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@source/administration-guide/onboard/sso-saml-entraid.rst` around lines 188 -
191, Replace the current note admonition with a warning admonition so the SAML
username-claim guidance is shown as a risk (change the RST block that starts
with ".. note::" and contains the lines referencing "user.mailnickname",
"user.userprincipalname" and "mailnickname" to use ".. warning::" instead);
ensure the block content remains identical besides the admonition type so the
explanation about using mailnickname (and the fallback option for custom Entra
attribute or UPN transformation) is preserved under the warning.
Copilot
AI
Apr 21, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Novice Nate (Friction): The note explains that Mattermost usernames can’t contain “@”, but Mattermost usernames also have other constraints (must start with a letter, 3–22 lowercase chars, only . - _ as symbols). user.mailnickname can be empty/inconsistent, contain uppercase, or be too short/long, which can still cause SAML sign-in failures even without “@”. Suggest expanding this note to include the full username constraints and recommending a claim transformation to lowercase/validate length (or using a dedicated custom attribute) when mailnickname doesn’t conform.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for SAML attribute configuration documentation
rg -n -C5 'Guest.*Attribute|Admin.*Attribute|Nickname.*Attribute|Preferred.*Language.*Attribute' source/ --type rst -g '!onboard/sso-saml-entraid.rst'Repository: mattermost/docs
Length of output: 35455
🏁 Script executed:
# Search for Locale attribute in SAML configuration
rg -n 'locale.*attribute|Locale.*Attribute' source/administration-guide/configure/authentication-configuration-settings.rst -i -A 5 -B 2Repository: mattermost/docs
Length of output: 1808
🏁 Script executed:
# Check the exact context in the file being reviewed
cat -n source/administration-guide/onboard/sso-saml-entraid.rst | sed -n '190,210p'Repository: mattermost/docs
Length of output: 2613
Update terminology to match official Mattermost SAML documentation.
Line 199 mentions "Preferred Language attributes" but the official System Console setting is labeled "Preferred language attribute" in the SAML 2.0 authentication configuration. All four attributes (Guest, Admin, Nickname, and Preferred language) are valid and configurable in Mattermost, so the guidance is sound—update the capitalization to "Preferred language attribute" for consistency with the official UI label.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@source/administration-guide/onboard/sso-saml-entraid.rst` at line 199, Update
the UI wording in the sentence that lists configurable SAML attributes: replace
the phrase "Preferred Language" with the exact System Console label "Preferred
language attribute" so the sentence reads "... Guest, Admin, Nickname, and
Preferred language attribute ..." to match Mattermost's official SAML 2.0
authentication configuration terminology.
Copilot
AI
Apr 21, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Veteran Vince (Friction): “The Import dialog says to upload a certificate with a file extension .cer, but .crt files are also accepted.” is a behavioral claim that may not hold in all Entra tenants/UX variants. To avoid a dead-end for admins, suggest wording this more defensively (e.g., “If Entra rejects .crt, rename/convert the file to .cer and try again”).
| 14. In the **Mattermost** enterprise application settings, select **Security > Token encryption**. Select **Import Certificate** to import the Service Provider certificate. If you used the Bash script referenced in the **Before you begin** section, this is the ``mattermost-x509.crt`` file. The Import dialog says to upload a certificate with a file extension ``.cer``, but ``.crt`` files are also accepted. Upload the file then select **Add**. | |
| 14. In the **Mattermost** enterprise application settings, select **Security > Token encryption**. Select **Import Certificate** to import the Service Provider certificate. If you used the Bash script referenced in the **Before you begin** section, this is the ``mattermost-x509.crt`` file. If Entra accepts the ``.crt`` file, upload it and select **Add**. If Entra rejects it because it expects a ``.cer`` file, rename or convert the certificate to ``.cer`` and try again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🌐 Web query:
What causes Microsoft Entra ID SAML error AADSTS90015 "Requested query string is too long" and how does request signing affect this?
💡 Result:
The Microsoft Entra ID SAML error AADSTS90015, "Requested query string is too long" (also described officially as "QueryStringTooLong - The query string is too long"), occurs when the incoming authentication request's query string exceeds the 4096-byte limit enforced by Entra ID's HTTP listener input validation. Primary causes in SAML contexts: - Use of HTTP-Redirect binding (GET) for AuthnRequest, where the base64-encoded, deflated SAMLRequest parameter (plus RelayState) becomes oversized. Common when the SAML assertion includes many groups/claims or long parameters. - Signed SAML requests over HTTP-Redirect: Signing adds extra query parameters (Signature and SigAlg), substantially increasing length since the signature is appended to the URL rather than embedded in the body. - Long RelayState values (SAML standard limits to 80 bytes, but apps often exceed this). - Accumulated browser cookies or other query parameters pushing over the limit. Request signing exacerbates this specifically in HTTP-Redirect binding. When the service provider (SP) signs the AuthnRequest: - The signature is not embedded in the SAML XML (as in POST); instead, separate Signature={base64 sig} and SigAlg={algorithm} parameters are added to the query string. - This can add hundreds of bytes, easily exceeding limits on already large requests. Solutions: - Switch to HTTP-POST binding for the AuthnRequest (preferred for signed requests), which sends the SAMLRequest in the POST body (no query string limit issue). Configure in the SP application settings (e.g., vendor UI, web.config). - Disable SAML request signing if not required (Entra ID does not enforce or validate signed incoming AuthnRequests by default). - Shorten RelayState (ask app vendor). - Clear excessive browser cookies for microsoftonline.com domains as a temporary workaround. - Use tools like Fiddler to capture and measure the SAMLRequest query string size. Official Entra ID error reference confirms the description with no additional SAML-specific details. Microsoft Q&A threads from Entra staff provide the most direct SAML guidance.
Citations:
- 1: https://learn.microsoft.com/en-us/answers/questions/2260686/aadsts90015-requested-query-string-is-too-long
- 2: https://learn.microsoft.com/en-us/answers/questions/31352/how-to-fix-azure-single-sign-on-error-aadsts90015
- 3: https://learn.microsoft.com/en-us/answers/questions/1043724/okta-with-azure-sso-error-requested-query-string-t
- 4: https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes
- 5: https://aka.ms/AADsigninsErrorCodes
Clarify the AADSTS90015 error mechanism and the role of request signing.
The explanation that Entra ID uses HTTP-Redirect (GET) is correct, but it omits critical context: the error occurs because GET binding places the SAML request and the signature parameters in the query string, which must not exceed 4096 bytes. When you enable signed requests, the Signature and SigAlg parameters are appended to the URL rather than embedded in the body, substantially increasing the query string size. Rewrite to explain that signing amplifies the risk of exceeding Entra ID's query string size limit, and note that switching to HTTP-POST binding avoids this constraint entirely.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@source/administration-guide/onboard/sso-saml-entraid.rst` at line 240, Update
the paragraph that begins "The **Test single sign-on with Mattermost SAML**
tool..." to explicitly state that Entra ID's HTTP-Redirect (GET) binding places
the encoded SAMLRequest and any signature parameters (Signature and SigAlg) into
the URL query string, which can exceed Entra ID's ~4096-byte limit; explain that
enabling "Sign Request" appends Signature and SigAlg to the query string and
therefore increases the risk of hitting AADSTS90015, and add that using
HTTP-POST binding (which embeds the SAML payload and signature in the request
body) avoids this query-string size constraint.
Copilot
AI
Apr 21, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Persona: Editor Evie | Severity: Friction
Quoted text/behavior: The :start-after: :nosearch: option under the final .. include:: sso-saml-faq.rst directive is indented with a tab.
Why it matters: Tabs in reStructuredText indentation can lead to inconsistent rendering or Sphinx warnings depending on configuration; spaces are the safer, standard indentation.
Suggestion: Replace the tab indentation with spaces (matching the include option indentation style used elsewhere in the docs).
| :start-after: :nosearch: | |
| :start-after: :nosearch: |
Copilot
AI
Apr 21, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Editor Evie (Polish): The .. include:: option lines at the end of the file are indented with a tab (\t:start-after: ...), while earlier directives in this file use spaces for indentation (e.g., the badges include). Tabs work but tend to cause inconsistent rendering/linting across editors. Suggestion: replace the tabs with consistent two-space indentation for the :start-after: options.
Copilot
AI
Apr 21, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Editor Evie (Blocker): The .. include:: option lines at the end of the file are indented with a literal tab (e.g., \t:start-after: :nosearch:). Tabs can render inconsistently and can break Sphinx/reStructuredText directive option parsing in some toolchains. Suggest replacing the tabs with spaces (matching the indentation used earlier in the file for include options).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Persona: Novice Nate | Severity: Blocker
Quoted text: “set Assignment required? to No”
Why it matters: Setting Assignment required? to No can allow any user in the Entra tenant to sign in to the application (depending on other access controls), which is a meaningful security/operational change. Readers may follow this without realizing the access scope implications.
Suggestion: Add a brief note calling out the tradeoff (recommended: keep assignment required and explicitly assign users/groups; only set it to No if you intentionally want broad access).