Configure SAML with Microsoft ADFS using Microsoft Windows Server 2016

This document provides steps to configure SAML 2.0 with Microsoft ADFS for Mattermost and Microsoft Windows Server 2016.

Before You Begin

Starting with Mattermost version 5.20, a new SAML library implementation is available. This implementation does not require the installation of the XML Security Library. It is recommended that you use this new implementation as the old implementation will eventually be deprecated.

To use the new implementation, navigate to System Console > Experimental > Features > Use Improved SAML Library (Beta). Select true, choose Save, and restart the server. The configuration change will not take effect until the server is restarted.

To change the configuration file directly, edit UseNewSAMLLibrary using the configuration provided in the Configuration Settings documentation.

To use the existing implementation in versions prior to 5.20:

  1. Make sure you have the XML Security Library installed on your Mattermost instance. The XML Security Library is usually included as part of Debian GNU/Linux.
  2. Install the xmlsec1-openssl library
  • On Ubuntu: sudo apt-get install xmlsec1
  • On RHEL: sudo yum install xmlsec1-openssl
  1. Generate encryption certificates for encrypting the SAML connection.
  1. You can use the Bash script from the mattermost/docs repository on GitHub, or any other suitable method.
  2. Save the two files that are generated. They are the private key and the public key. In the System Console, they are referred to as the Service Provider Private Key and the Service Provider Public Certificate respectively.

Prerequisites

  • An Active Directory instance where all users have specified email and username attributes. For Mattermost servers running 3.3 and earlier, users must also have their first name and last name attributes specified.
  • A running Microsoft Server. The screenshots used in this guide are from Microsoft Server 2012R2, but similar steps should work for other versions.
  • An SSL certificate to sign your ADFS login page.
  • ADFS installed on your Microsoft Server. You can find a detailed guide for deploying and configuring ADFS in this article.

On your ADFS installation, open the ADFS console. Select Service and then Endpoints. In the Type column search for SAML 2.0/WS-Federation and note down the value of URL Path column. This is also known as the SAML SSO URL Endpoint in this guide. If you chose the defaults for the installation, this will be /adfs/ls.

Add a Relying Party Trust

  1. Open the ADFS management snap-in and select AD FS > Relying Party Trusts > Add Relying Party Trust on the right sidebar. You can also right-click Relying Party Trusts and choose Add Relying Party Trust from the context menu.

    ../_images/SSO-SAML-ADFS_add-new-relying-party-trust_000.png
  2. In the Welcome screen of the configuration wizard choose Claims aware and select Start.

    ../_images/SSO-SAML-ADFS_add-new-relying-party-trust_001.png
  3. In the Select Data Source screen, choose Enter data about the relying party manually.

    ../_images/SSO-SAML-ADFS_add-new-relying-party-trust_002.png
  4. In the Specify Display Name screen enter a Display Name (e.g., Mattermost). You can add optional notes.

    ../_images/SSO-SAML-ADFS_add-new-relying-party-trust_003.png
  5. In the Configure Certificate screen, leave the certificate settings at their default values.

    ../_images/SSO-SAML-ADFS_add-new-relying-party-trust_004.png

If you would like to set up encryption for your SAML connection, select Browse and upload your Service Provider Public Certificate.

../_images/SSO-SAML-ADFS_add-new-relying-party-trust_005.png
  1. In the Configure URL screen, select Enable Support for the SAML 2.0 WebSSO protocol and enter the SAML 2.0 SSO service URL in the following format:https://<your-mattermost-url>/login/sso/saml where <your-mattermost-url> should typically match the Mattermost Site URL.

    ../_images/SSO-SAML-ADFS_add-new-relying-party-trust_006.png
  2. In the Configure Identifiers screen, enter the Relying party trust identifier. This identifies the claims being requested. The SAML 2.0 SSO service URL format should be https://<your-mattermost-url>/login/sso/saml where <your-mattermost-url> matches your Mattermost Site URL. Then choose Next.

    ../_images/SSO-SAML-ADFS_add-new-relying-party-trust_007.png ../_images/SSO-SAML-ADFS_add-new-relying-party-trust_008.png

This string must match the Service Provider Identifier string. For more information about the Relying party trust identifier and how prefix matching is applied see this documentation.

Add your SAML 2.0 SSO service URL from above the same way.

  1. In the Choose Access Control Policy screen select the access control policy suitable for your environment. This guide assumes the default values Permit everyone and an unchecked box.

    ../_images/SSO-SAML-ADFS_add-new-relying-party-trust_009.png
  2. In the Ready to Add Trust screen, you can review your settings.

    ../_images/SSO-SAML-ADFS_add-new-relying-party-trust_010.png
  3. In the Finish screen select Configure claims issuance policy for this application and then Close.

    ../_images/SSO-SAML-ADFS_add-new-relying-party-trust_011.png

Create Claim Rules

  1. In the Issuance Transform Rules tab of the Claim Rules editor, choose Add Rule….

    ../_images/SSO-SAML-ADFS_create-claim-rules_001.png
  2. In the Choose Rule Type screen, select Send LDAP Attributes as Claims from the drop-down menu, then click Next.

    ../_images/SSO-SAML-ADFS_create-claim-rules_002.png
  3. In the Configure Claim Rule screen, enter a Claim Rule Name of your choice, select Active Directory as the Attribute Store and add the following mapping:

  • From the LDAP Attribute column, select E-Mail-Addresses. From the Outgoing Claim Type, type Email
  • From the LDAP Attribute column, select Given-Name. From the Outgoing Claim Type, type FirstName
  • From the LDAP Attribute column, select Surname. From the Outgoing Claim Type, type LastName
  • From the LDAP Attribute column, select SAM-Account-Name. From the Outgoing Claim Type, type Username

For Mattermost 3.4 and later, the FirstName and LastName attributes are optional.

Select Finish to add the rule.

The entries in the Outgoing Claim Type column can be modified and the entries may contain dashes but no spaces. They are used to map the corresponding fields in Mattermost.

../_images/SSO-SAML-ADFS_create-claim-rules_003.png
  1. Select Add Rule to create another new rule.

  2. In the Choose Rule Type screen, select Transform an Incoming Claim from the drop-down menu, then click Next.

    ../_images/SSO-SAML-ADFS_create-claim-rules_004.png
  3. In the Configure Claim Rule screen, enter a Claim Rule Name of your choice, then

  • Select Name ID for the Incoming claim type
  • Select Unspecified for the Incoming name ID format
  • Select E-Mail Address for the Outgoing claim type

Select the Pass through all claim values option and click Finish.

../_images/SSO-SAML-ADFS_create-claim-rules_005.png
  1. Click Finish to create the claim rule, then OK to finish creating rules.
  2. Open Windows PowerShell as an administrator and run the following command:
Set-ADFSRelyingPartyTrust -TargetName <display-name> -SamlResponseSignature "MessageAndAssertion"

where <display-name> is the name you specified in step 4 of Add a Relying Party Trust. In our example it would be mattermost.

This action will add the signature to SAML messages, making verification successful.

Export Identity Provider Certificate

Next, we export the identity provider certificate, which will be later uploaded to Mattermost to finish SAML configuration.

  1. Open the ADFS management snap-in, select AD FS > Service > Certificates and double click on the certificate under Token-signing. You can also right-click the field, then click View Certificate in the context menu.

    ../_images/SSO-SAML-ADFS_export-id-provider-cert_001.png
  2. In the Certificate screen open the the Details tab, select Copy to File and then OK.

    ../_images/SSO-SAML-ADFS_export-id-provider-cert_003.png
  3. In the Certificate Export Wizard screen, click Next.

    ../_images/SSO-SAML-ADFS_export-id-provider-cert_004.png

    Then, select the option Base-64 encoded X.509 (.CER) and click Next again.

    ../_images/SSO-SAML-ADFS_export-id-provider-cert_005.png
  4. In the Certificate Export Wizard screen, click Browse to specify the location you want the Identity Provider Certificate to be exported, and specify the file name.

    ../_images/SSO-SAML-ADFS_export-id-provider-cert_006.png
  5. Click Save. In the Certificate Export Wizard screen, verify the file path is correct, and click Next.

  6. In the Completing the Certificate Export Wizard, click Finish, then OK to confirm the export was successful.

    ../_images/SSO-SAML-ADFS_export-id-provider-cert_007.png

Configure SAML Sign-in for Mattermost

Create a metadata URL by appending “FederationMetadata/2007-06/FederationMetadata.xml” to the root URL of the ADFS server, for example: https://<adfs.domain.com>/federationmetadata/2007-06/FederationMetadata.xml>.

Next, start Mattermost server and sign into Mattermost as a System Administrator. Go to System Console > Authentication > SAML, paste the metadata URL in the Identity Provider Metadata URL field, and then select Get SAML Metadata from IdP.

This populates the SAML SSO URL and the Identity Provider Issuer URL fields automatically and the Identity Provider Public Certificate is also downloaded from the server and set locally.

The following fields can be selected:
  • Set Enable Login With SAML 2.0 to true.
  • Set Enable Synchronizing SAML Accounts With AD/LDAP to suit your environment.
  • Set Override SAML bind data with AD/LDAP information to suit your environment.
If you don’t plan to use a metadata URL you can manually enter the following fields:
  • For SAML SSO URL use the SAML 2.0/W-Federation URL ADFS Endpoint you copied at the beginning of the process.

  • For Identity Provider Issuer URL use the Relying party trust identifier from ADFS.

  • For Identity Provider Public Certificate use the``X.509 Public Certificate``.

    ../_images/SSO-SAML-ADFS_configure-saml_001.png
  1. Configure Mattermost to verify the signature.
  • Set Verify Signature to true.

  • For Service Provider Login URL use the SAML 2.0 SSO service URL you specified in ADFS.

    ../_images/SSO-SAML-ADFS_configure-saml_002.png
  1. Enable encryption.
  • Set Enable Encryption to true.

  • For Service Provider Private Key use the Service Provider Private Key generated at the start of this process.

  • For Service Provider Public Certificate use the Service Provider Public Certificate you generated at the start of this process.

  • Set Sign Request to suit your environment.

    ../_images/SSO-SAML-ADFS_configure-saml_003.png
  1. Set attributes for the SAML Assertions, which will be used to update user information in Mattermost. Attributes for email and username are required and should match the values you entered in ADFS earlier. See documentation on SAML configuration settings for more detail.

For Mattermost servers running 3.3 and earlier, the first name and last name attributes are also required fields.

../_images/SSO-SAML-ADFS_configure-saml_004.png
  1. Click Save.
  2. (Optional) If you configured First Name Attribute and Last Name Attribute, go to System Console > Site Configuration > Users and Teams (or System Console > General > Users and Teams in versions prior to 5.12) and set Teammate Name Display to Show first and last name. This is recommended for a better user experience.

You’re done! If you’d like to confirm SAML SSO is successfully enabled, switch your System Administrator account from email to SAML-based authentication via Account Settings > General > Sign-in Method > Switch to SAML SSO and sign in with your SAML credentials to complete the switch.

It’s also recommended to post an announcement about how the migration will work to users.

You may also configure SAML for ADFS by editing config.json to enable SAML based on SAML configuration settings. You must restart the Mattermost server for the changes to take effect.

Frequently Asked Questions

How to Bind Authentication to Id Attribute instead of Email

Alternatively, you can use an Id Attribute instead of email to bind the user. We recommend choosing an ID that is unique and will not change over time.

Configuring with an Id Attribute allows you to reuse an email address for a new user without the old user’s information being exposed. For instance, if a user with an email address joe.smith@mattermost.com was once an employee, a new employee named Joe Smith can use the same email. This configuration is also useful when a user’s name changes and their email needs to be updated.

This process was designed with backwards compatibility to email binding. Here is the process applied to new account creations and to accounts logging in after the configuration:

  • A user authenticated with SAML is bound to the SAML service user using the Id Attribute (as long as it has been configured) or bound by email using the email received from SAML.
  • When the user tries to login and the SAML server responds with a valid authentication, then the server uses the “Id” field of the SAML authentication to search the user.
  • If a user bound to that ID already exists, it logs in as that user.
  • If a user bound to that ID does not exist, it will search base on the email.
  • If a user bound to the email exists, it logs in with email and updates the autentication data to the ID, instead of the email.
  • If a user bound to the ID or email does not exist, it will create a new Mattermost account bound to the SAML account by ID and will allow the user to log in.

Note: Existing accounts will not update until they log in to the server.

Can SAML via Microsoft ADFS be configured with Integrated Windows Authentication (IWA)?

Yes. IWA is supported on the browser, with support added to iOS and Android mobile apps in Q2/2019 (mobile apps v1.18 and later).

However, IWA is not supported on the Mattermost Desktop Apps due to a limitation in Electron. As a workaround you may create a browser desktop shortcut for quick access to Mattermost, just like a Desktop App.

How do I migrate users from one authentication method (e.g. email) to SAML?

Use the mattermost user migrate_auth CLI command.

How is SAML different from OAuth 2.0 and OpenId Connect?

OAuth 2.0 was primarily intended for delegated authorization, where an app is authorized to access resources, such as Google contact list. It doesn’t deal with authentication.

OpenID Connect is built on top of OAuth 2.0, which supports authentication and thus direct SSO.

SAML is like OpenID Connect, except typically used in enterprise settings. OpenID Connect is more common in consumer websites and web/mobile apps.

Learn more at https://hackernoon.com/demystifying-oauth-2-0-and-openid-connect-and-saml-12aa4cf9fdba.

Configure SAML synchronization with AD/LDAP

In addition to configuring SAML sign-in, you can optionally configure synchronizing SAML accounts with AD/LDAP. When configured:

  • Mattermost queries AD/LDAP for relevant account information and updates SAML accounts based on changes to attributes (first name, last name, and nickname)
  • Accounts disabled in AD/LDAP are made inactive in Mattermost, and their active sessions are revoked once Mattermost synchronizes attributes.

To configure SAML synchronization with AD/LDAP:

  1. Go to System Console > Authentication > SAML 2.0 (or System Console > SAML in versions prior to 5.12) and set Enable Synchronizing SAML Accounts With AD/LDAP to true.
  2. Go to System Console > Authentication > AD/LDAP (or System Console > AD/LDAP in versions prior to 5.12) and set Enable Synchronization with AD/LDAP to true.
  3. Set the rest of the AD/LDAP settings based on configuration settings documentation to connect Mattermost with your AD/LDAP server.
  • If you don’t want to enable AD/LDAP sign-in, keep Enable sign-in with AD/LDAP as false.
  1. Set Syncronization Interval to specify how often Mattermost synchronizes SAML user accounts with AD/LDAP. The default setting is 60 minutes. If you want to synchronize immediately after disabling an account, use the “AD/LDAP Synchronize Now” button in System Console > AD/LDAP in prior versions or System Console > Authentication > AD/LDAP in versions after 5.12.
  2. To test Mattermost can successfully connect to your AD/LDAP server, click the AD/LDAP Test button.

Once the synchronization with AD/LDAP is enabled, user attributes are synchronized with AD/LDAP based on their email address. If a user with a given email address doesn’t have an AD/LDAP account, they will be deactivated in Mattermost on the next AD/LDAP sync. To re-activate the account:

  1. Add the user to your AD/LDAP server.
  2. Purge all caches in Mattermost in System Console > Web Server > Purge All Caches (or System Console > Configuration > Purge All Caches in versions prior to 5.12).
  3. Run AD/LDAP sync in System Console > Authentication > AD/LDAP > AD/LDAP Synchronize Now (or System Console > AD/LDAP > AD/LDAP Synchronize Now in versions prior to 5.12).
  4. Purge all caches again in Mattermost in System Console > Web Server > Purge All Caches (or System Console > Configuration > Purge All Caches in versions prior to 5.12), which re-activates the account in Mattermost.

Note

If a user is deactivated from AD/LDAP, they will be deactivated in Mattermost on the next sync. They will be shown as “Inactive” in the System Console users list, all of their sessions will expire and they won’t be able to log back in to Mattermost.

If a user is deactivated from SAML, their session won’t expire until they’re deactivated from AD/LDAP. However, they won’t be able to log back in to Mattermost.

Note

SAML synchronization with AD/LDAP is designed to pull user attributes such as first name and last name from your AD/LDAP, not to control authentication.

In particular, the user filter cannot be used to control who can log in to Mattermost, this should be controlled by your SAML service provider’s group permissions.

See technical description of SAML synchronization with AD/LDAP for more details.

Override SAML Data with AD/LDAP Data

Alternatively, you can choose to override SAML bind data with AD/LDAP information. For more infomation on binding a user with the SAML ID Attribute, please refer to this documentation.

This process overrides SAML email address with AD/LDAP email address data or SAML Id Attribute with AD/LDAP Id Attribute if configured. We recommend using this configuration with the SAML ID Attribute to help ensure new users are not created when the email address changes for a user.

To ensure existing user accounts do not get disabled in this process, ensure the SAML IDs match the LDAP IDs by exporting data from both systems and comparing the ID data. Mapping ID Attributes for both AD/LDAP and SAML within Mattermost to fields that hold the same data will ensure the IDs match as well.

  1. Set the SAML Id Attribute on System Console > Authentication > SAML 2.0 > Id Attribute (or System Console > SAML > Id Attribute in versions prior to 5.12)
  2. Set System Console > Authentication > SAML 2.0 > Override SAML bind data with AD/LDAP information (or System Console > SAML > Override SAML bind data with AD/LDAP information in versions prior to 5.12) to true.
  3. Set System Console > Authentication > SAML 2.0 > Enable Synchronizing SAML Accounts With AD/LDAP (or System Console > SAML > Enable Synchronizing SAML Accounts With AD/LDAP in versions prior to 5.12) to true.
  4. Run AD/LDAP sync in System Console > Authentication > AD/LDAP > AD/LDAP Synchronize Now (or System Console > AD/LDAP > AD/LDAP Synchronize Now in versions prior to 5.12).