config_documentation.md

```yaml
recaptcha_public_key: "YOUR_PUBLIC_KEY"
```
---
### `recaptcha_private_key`

This homeserver's ReCAPTCHA private key. Must be specified if
[`enable_registration_captcha`](#enable_registration_captcha) is
enabled.

Example configuration:
```yaml
recaptcha_private_key: "YOUR_PRIVATE_KEY"
```
---
### `enable_registration_captcha`

Set to `true` to require users to complete a CAPTCHA test when registering an account.
Requires a valid ReCaptcha public/private key.
Defaults to `false`.

Note that [`enable_registration`](#enable_registration) must also be set to allow account registration.

Example configuration:
```yaml
enable_registration_captcha: true
```
---
### `recaptcha_siteverify_api`

The API endpoint to use for verifying `m.login.recaptcha` responses.
Defaults to `https://www.recaptcha.net/recaptcha/api/siteverify`.

Example configuration:
```yaml
recaptcha_siteverify_api: "https://my.recaptcha.site"
```
---
## TURN
Options related to adding a TURN server to Synapse.

---
### `turn_uris`

The public URIs of the TURN server to give to clients.

Example configuration:
```yaml
turn_uris: [turn:example.org]
```
---
### `turn_shared_secret`

The shared secret used to compute passwords for the TURN server.

Example configuration:
```yaml
turn_shared_secret: "YOUR_SHARED_SECRET"
```
---
### `turn_username` and `turn_password`

The Username and password if the TURN server needs them and does not use a token.

Example configuration:
```yaml
turn_username: "TURNSERVER_USERNAME"
turn_password: "TURNSERVER_PASSWORD"
```
---
### `turn_user_lifetime`

How long generated TURN credentials last. Defaults to 1h.

Example configuration:
```yaml
turn_user_lifetime: 2h
```
---
### `turn_allow_guests`

Whether guests should be allowed to use the TURN server. This defaults to true, otherwise
VoIP will be unreliable for guests. However, it does introduce a slight security risk as
it allows users to connect to arbitrary endpoints without having first signed up for a valid account (e.g. by passing a CAPTCHA).

Example configuration:
```yaml
turn_allow_guests: false
```
---
## Registration ##

Registration can be rate-limited using the parameters in the [Ratelimiting](#ratelimiting) section of this manual.

---
### `enable_registration`

Enable registration for new users. Defaults to `false`.

It is highly recommended that if you enable registration, you set one or more
or the following options, to avoid abuse of your server by "bots":

 * [`enable_registration_captcha`](#enable_registration_captcha)
 * [`registrations_require_3pid`](#registrations_require_3pid)
 * [`registration_requires_token`](#registration_requires_token)

(In order to enable registration without any verification, you must also set
[`enable_registration_without_verification`](#enable_registration_without_verification).)

Note that even if this setting is disabled, new accounts can still be created
via the admin API if
[`registration_shared_secret`](#registration_shared_secret) is set.

Example configuration:
```yaml
enable_registration: true
```
---
### `enable_registration_without_verification`

Enable registration without email or captcha verification. Note: this option is *not* recommended,
as registration without verification is a known vector for spam and abuse. Defaults to `false`. Has no effect
unless [`enable_registration`](#enable_registration) is also enabled.

Example configuration:
```yaml
enable_registration_without_verification: true
```
---
### `registrations_require_3pid`

If this is set, users must provide all of the specified types of 3PID when registering an account.

Note that [`enable_registration`](#enable_registration) must also be set to allow account registration.

Example configuration:
```yaml
registrations_require_3pid:
  - email
  - msisdn
```
---
### `disable_msisdn_registration`

Explicitly disable asking for MSISDNs from the registration
flow (overrides `registrations_require_3pid` if MSISDNs are set as required).

Example configuration:
```yaml
disable_msisdn_registration: true
```
---
### `allowed_local_3pids`

Mandate that users are only allowed to associate certain formats of
3PIDs with accounts on this server, as specified by the `medium` and `pattern` sub-options.

Example configuration:
```yaml
allowed_local_3pids:
  - medium: email
    pattern: '^[^@]+@matrix\.org$'
  - medium: email
    pattern: '^[^@]+@vector\.im$'
  - medium: msisdn
    pattern: '\+44'
```
---
### `enable_3pid_lookup`

Enable 3PIDs lookup requests to identity servers from this server. Defaults to true.

Example configuration:
```yaml
enable_3pid_lookup: false
```
---
### `registration_requires_token`

Require users to submit a token during registration.
Tokens can be managed using the admin [API](../administration/admin_api/registration_tokens.md).
Disabling this option will not delete any tokens previously generated.
Defaults to `false`. Set to `true` to enable.


Note that [`enable_registration`](#enable_registration) must also be set to allow account registration.

Example configuration:
```yaml
registration_requires_token: true
```
---
### `registration_shared_secret`

If set, allows registration of standard or admin accounts by anyone who has the
shared secret, even if [`enable_registration`](#enable_registration) is not
set.

This is primarily intended for use with the `register_new_matrix_user` script
(see [Registering a user](../../setup/installation.md#registering-a-user));
however, the interface is [documented](../../admin_api/register_api.html).

See also [`registration_shared_secret_path`](#registration_shared_secret_path).

Example configuration:
```yaml
registration_shared_secret: <PRIVATE STRING>
```

---
### `registration_shared_secret_path`

An alternative to [`registration_shared_secret`](#registration_shared_secret):
allows the shared secret to be specified in an external file.

The file should be a plain text file, containing only the shared secret.

If this file does not exist, Synapse will create a new signing
key on startup and store it in this file.

Example configuration:
```yaml
registration_shared_secret_file: /path/to/secrets/file
```

_Added in Synapse 1.67.0._

---
### `bcrypt_rounds`

Set the number of bcrypt rounds used to generate password hash.
Larger numbers increase the work factor needed to generate the hash.
The default number is 12 (which equates to 2^12 rounds).
N.B. that increasing this will exponentially increase the time required
to register or login - e.g. 24 => 2^24 rounds which will take >20 mins.
Example configuration:
```yaml
bcrypt_rounds: 14
```
---
### `allow_guest_access`

Allows users to register as guests without a password/email/etc, and
participate in rooms hosted on this server which have been made
accessible to anonymous users. Defaults to false.

Example configuration:
```yaml
allow_guest_access: true
```
---
### `default_identity_server`

The identity server which we suggest that clients should use when users log
in on this server.

(By default, no suggestion is made, so it is left up to the client.
This setting is ignored unless `public_baseurl` is also explicitly set.)

Example configuration:
```yaml
default_identity_server: https://matrix.org
```
---
### `account_threepid_delegates`

Delegate verification of phone numbers to an identity server.

When a user wishes to add a phone number to their account, we need to verify that they
actually own that phone number, which requires sending them a text message (SMS).
Currently Synapse does not support sending those texts itself and instead delegates the
task to an identity server. The base URI for the identity server to be used is
specified by the `account_threepid_delegates.msisdn` option.

If this is left unspecified, Synapse will not allow users to add phone numbers to
their account.

(Servers handling the these requests must answer the `/requestToken` endpoints defined
by the Matrix Identity Service API
[specification](https://matrix.org/docs/spec/identity_service/latest).)

*Deprecated in Synapse 1.64.0*: The `email` option is deprecated.

*Removed in Synapse 1.66.0*: The `email` option has been removed.
If present, Synapse will report a configuration error on startup.

Example configuration:
```yaml
account_threepid_delegates:
    msisdn: http://localhost:8090  # Delegate SMS sending to this local process
```
---
### `enable_set_displayname`

Whether users are allowed to change their displayname after it has
been initially set. Useful when provisioning users based on the
contents of a third-party directory.

Does not apply to server administrators. Defaults to true.

Example configuration:
```yaml
enable_set_displayname: false
```
---
### `enable_set_avatar_url`

Whether users are allowed to change their avatar after it has been
initially set. Useful when provisioning users based on the contents
of a third-party directory.

Does not apply to server administrators. Defaults to true.

Example configuration:
```yaml
enable_set_avatar_url: false
```
---
### `enable_3pid_changes`

Whether users can change the third-party IDs associated with their accounts
(email address and msisdn).

Defaults to true.

Example configuration:
```yaml
enable_3pid_changes: false
```
---
### `auto_join_rooms`

Users who register on this homeserver will automatically be joined
to the rooms listed under this option.

By default, any room aliases included in this list will be created
as a publicly joinable room when the first user registers for the
homeserver. If the room already exists, make certain it is a publicly joinable
room, i.e. the join rule of the room must be set to 'public'. You can find more options
relating to auto-joining rooms below.

As Spaces are just rooms under the hood, Space aliases may also be
used.

Example configuration:
```yaml
auto_join_rooms:
  - "#exampleroom:example.com"
  - "#anotherexampleroom:example.com"
```
---
### `autocreate_auto_join_rooms`

Where `auto_join_rooms` are specified, setting this flag ensures that
the rooms exist by creating them when the first user on the
homeserver registers. This option will not create Spaces.

By default the auto-created rooms are publicly joinable from any federated
server. Use the `autocreate_auto_join_rooms_federated` and
`autocreate_auto_join_room_preset` settings to customise this behaviour.

Setting to false means that if the rooms are not manually created,
users cannot be auto-joined since they do not exist.

Defaults to true.

Example configuration:
```yaml
autocreate_auto_join_rooms: false
```
---
### `autocreate_auto_join_rooms_federated`

Whether the rooms listed in `auto_join_rooms` that are auto-created are available
via federation. Only has an effect if `autocreate_auto_join_rooms` is true.

Note that whether a room is federated cannot be modified after
creation.

Defaults to true: the room will be joinable from other servers.
Set to false to prevent users from other homeservers from
joining these rooms.

Example configuration:
```yaml
autocreate_auto_join_rooms_federated: false
```
---
### `autocreate_auto_join_room_preset`

The room preset to use when auto-creating one of `auto_join_rooms`. Only has an
effect if `autocreate_auto_join_rooms` is true.

Possible values for this option are:
* "public_chat": the room is joinable by anyone, including
  federated servers if `autocreate_auto_join_rooms_federated` is true (the default).
* "private_chat": an invitation is required to join these rooms.
* "trusted_private_chat": an invitation is required to join this room and the invitee is
  assigned a power level of 100 upon joining the room.

If a value of "private_chat" or "trusted_private_chat" is used then
`auto_join_mxid_localpart` must also be configured.

Defaults to "public_chat".

Example configuration:
```yaml
autocreate_auto_join_room_preset: private_chat
```
---
### `auto_join_mxid_localpart`

The local part of the user id which is used to create `auto_join_rooms` if
`autocreate_auto_join_rooms` is true. If this is not provided then the
initial user account that registers will be used to create the rooms.

The user id is also used to invite new users to any auto-join rooms which
are set to invite-only.

It *must* be configured if `autocreate_auto_join_room_preset` is set to
"private_chat" or "trusted_private_chat".

Note that this must be specified in order for new users to be correctly
invited to any auto-join rooms which have been set to invite-only (either
at the time of creation or subsequently).

Note that, if the room already exists, this user must be joined and
have the appropriate permissions to invite new members.

Example configuration:
```yaml
auto_join_mxid_localpart: system
```
---
### `auto_join_rooms_for_guests`

When `auto_join_rooms` is specified, setting this flag to false prevents
guest accounts from being automatically joined to the rooms.

Defaults to true.

Example configuration:
```yaml
auto_join_rooms_for_guests: false
```
---
### `inhibit_user_in_use_error`

Whether to inhibit errors raised when registering a new account if the user ID
already exists. If turned on, requests to `/register/available` will always
show a user ID as available, and Synapse won't raise an error when starting
a registration with a user ID that already exists. However, Synapse will still
raise an error if the registration completes and the username conflicts.

Defaults to false.

Example configuration:
```yaml
inhibit_user_in_use_error: true
```
---
## User session management
---
### `session_lifetime`

Time that a user's session remains valid for, after they log in.

Note that this is not currently compatible with guest logins.

Note also that this is calculated at login time: changes are not applied retrospectively to users who have already
logged in.

By default, this is infinite.

Example configuration:
```yaml
session_lifetime: 24h
```
---
### `refresh_access_token_lifetime`

Time that an access token remains valid for, if the session is using refresh tokens.

For more information about refresh tokens, please see the [manual](user_authentication/refresh_tokens.md).

Note that this only applies to clients which advertise support for refresh tokens.

Note also that this is calculated at login time and refresh time: changes are not applied to
existing sessions until they are refreshed.

By default, this is 5 minutes.

Example configuration:
```yaml
refreshable_access_token_lifetime: 10m
```
---
### `refresh_token_lifetime: 24h`

Time that a refresh token remains valid for (provided that it is not
exchanged for another one first).
This option can be used to automatically log-out inactive sessions.
Please see the manual for more information.

Note also that this is calculated at login time and refresh time:
changes are not applied to existing sessions until they are refreshed.

By default, this is infinite.

Example configuration:
```yaml
refresh_token_lifetime: 24h
```
---
### `nonrefreshable_access_token_lifetime`

Time that an access token remains valid for, if the session is NOT
using refresh tokens.

Please note that not all clients support refresh tokens, so setting
this to a short value may be inconvenient for some users who will
then be logged out frequently.

Note also that this is calculated at login time: changes are not applied
retrospectively to existing sessions for users that have already logged in.

By default, this is infinite.

Example configuration:
```yaml
nonrefreshable_access_token_lifetime: 24h
```

---
## Metrics
Config options related to metrics.

---
### `enable_metrics`

Set to true to enable collection and rendering of performance metrics.
Defaults to false.

Example configuration:
```yaml
enable_metrics: true
```
---
### `sentry`

Use this option to enable sentry integration. Provide the DSN assigned to you by sentry
with the `dsn` setting.

NOTE: While attempts are made to ensure that the logs don't contain
any sensitive information, this cannot be guaranteed. By enabling
this option the sentry server may therefore receive sensitive
information, and it in turn may then disseminate sensitive information
through insecure notification channels if so configured.

Example configuration:
```yaml
sentry:
    dsn: "..."
```
---
### `metrics_flags`

Flags to enable Prometheus metrics which are not suitable to be
enabled by default, either for performance reasons or limited use.
Currently the only option is `known_servers`, which publishes
`synapse_federation_known_servers`, a gauge of the number of
servers this homeserver knows about, including itself. May cause
performance problems on large homeservers.

Example configuration:
```yaml
metrics_flags:
    known_servers: true
```
---
### `report_stats`

Whether or not to report homeserver usage statistics. This is originally
set when generating the config. Set this option to true or false to change the current
behavior. See
[Reporting Homeserver Usage Statistics](../administration/monitoring/reporting_homeserver_usage_statistics.md)
for information on what data is reported.

Statistics will be reported 5 minutes after Synapse starts, and then every 3 hours
after that.

Example configuration:
```yaml
report_stats: true
```
---
### `report_stats_endpoint`

The endpoint to report homeserver usage statistics to.
Defaults to https://matrix.org/report-usage-stats/push

Example configuration:
```yaml
report_stats_endpoint: https://example.com/report-usage-stats/push
```
---
## API Configuration
Config settings related to the client/server API

---
### `room_prejoin_state`

This setting controls the state that is shared with users upon receiving an
invite to a room, or in reply to a knock on a room. By default, the following
state events are shared with users:

- `m.room.join_rules`
- `m.room.canonical_alias`
- `m.room.avatar`
- `m.room.encryption`
- `m.room.name`
- `m.room.create`
- `m.room.topic`

To change the default behavior, use the following sub-options:
* `disable_default_event_types`: boolean. Set to `true` to disable the above 
  defaults. If this is enabled, only the event types listed in
  `additional_event_types` are shared. Defaults to `false`.
* `additional_event_types`: A list of additional state events to include in the 
  events to be shared. By default, this list is empty (so only the default event 
  types are shared).

  Each entry in this list should be either a single string or a list of two
  strings. 
  * A standalone string `t` represents all events with type `t` (i.e.
    with no restrictions on state keys).
  * A pair of strings `[t, s]` represents a single event with type `t` and 
    state key `s`. The same type can appear in two entries with different state
    keys: in this situation, both state keys are included in prejoin state.

Example configuration:
```yaml
room_prejoin_state:
   disable_default_event_types: false
   additional_event_types:
     # Share all events of type `org.example.custom.event.typeA`
     - org.example.custom.event.typeA
     # Share only events of type `org.example.custom.event.typeB` whose
     # state_key is "foo"
     - ["org.example.custom.event.typeB", "foo"]
     # Share only events of type `org.example.custom.event.typeC` whose
     # state_key is "bar" or "baz"
     - ["org.example.custom.event.typeC", "bar"]
     - ["org.example.custom.event.typeC", "baz"]
```

*Changed in Synapse 1.74:* admins can filter the events in prejoin state based
on their state key.

---
### `track_puppeted_user_ips`

We record the IP address of clients used to access the API for various
reasons, including displaying it to the user in the "Where you're signed in"
dialog.

By default, when puppeting another user via the admin API, the client IP
address is recorded against the user who created the access token (ie, the
admin user), and *not* the puppeted user.

Set this option to true to also record the IP address against the puppeted
user. (This also means that the puppeted user will count as an "active" user
for the purpose of monthly active user tracking - see `limit_usage_by_mau` etc
above.)

Example configuration:
```yaml
track_puppeted_user_ips: true
```
---
### `app_service_config_files`

A list of application service config files to use.

Example configuration:
```yaml
app_service_config_files:
  - app_service_1.yaml
  - app_service_2.yaml
```
---
### `track_appservice_user_ips`

Defaults to false. Set to true to enable tracking of application service IP addresses.
Implicitly enables MAU tracking for application service users.

Example configuration:
```yaml
track_appservice_user_ips: true
```
---
### `macaroon_secret_key`

A secret which is used to sign
- access token for guest users,
- short-term login token used during SSO logins (OIDC or SAML2) and
- token used for unsubscribing from email notifications.

If none is specified, the `registration_shared_secret` is used, if one is given;
otherwise, a secret key is derived from the signing key.

Example configuration:
```yaml
macaroon_secret_key: <PRIVATE STRING>
```
---
### `form_secret`

A secret which is used to calculate HMACs for form values, to stop
falsification of values. Must be specified for the User Consent
forms to work.

Example configuration:
```yaml
form_secret: <PRIVATE STRING>
```
---
## Signing Keys
Config options relating to signing keys

---
### `signing_key_path`

Path to the signing key to sign events and federation requests with.

*New in Synapse 1.67*: If this file does not exist, Synapse will create a new signing
key on startup and store it in this file.

Example configuration:
```yaml
signing_key_path: "CONFDIR/SERVERNAME.signing.key"
```
---
### `old_signing_keys`

The keys that the server used to sign messages with but won't use
to sign new messages. For each key, `key` should be the base64-encoded public key, and
`expired_ts`should be the time (in milliseconds since the unix epoch) that
it was last used.

It is possible to build an entry from an old `signing.key` file using the
`export_signing_key` script which is provided with synapse.

Example configuration:
```yaml
old_signing_keys:
  "ed25519:id": { key: "base64string", expired_ts: 123456789123 }
```
---
### `key_refresh_interval`

How long key response published by this server is valid for.
Used to set the `valid_until_ts` in `/key/v2` APIs.
Determines how quickly servers will query to check which keys
are still valid. Defaults to 1d.

Example configuration:
```yaml
key_refresh_interval: 2d
```
---
### `trusted_key_servers`

The trusted servers to download signing keys from.

When we need to fetch a signing key, each server is tried in parallel.

Normally, the connection to the key server is validated via TLS certificates.
Additional security can be provided by configuring a `verify key`, which
will make synapse check that the response is signed by that key.

This setting supercedes an older setting named `perspectives`. The old format
is still supported for backwards-compatibility, but it is deprecated.

`trusted_key_servers` defaults to matrix.org, but using it will generate a
warning on start-up. To suppress this warning, set
`suppress_key_server_warning` to true.

If the use of a trusted key server has to be deactivated, e.g. in a private
federation or for privacy reasons, this can be realised by setting
an empty array (`trusted_key_servers: []`). Then Synapse will request the keys
directly from the server that owns the keys. If Synapse does not get keys directly
from the server, the events of this server will be rejected.

Options for each entry in the list include:
* `server_name`: the name of the server. Required.
* `verify_keys`: an optional map from key id to base64-encoded public key.
   If specified, we will check that the response is signed by at least
   one of the given keys.
* `accept_keys_insecurely`: a boolean. Normally, if `verify_keys` is unset,
   and `federation_verify_certificates` is not `true`, synapse will refuse
   to start, because this would allow anyone who can spoof DNS responses
   to masquerade as the trusted key server. If you know what you are doing
   and are sure that your network environment provides a secure connection
   to the key server, you can set this to `true` to override this behaviour.

Example configuration #1:
```yaml
trusted_key_servers:
  - server_name: "my_trusted_server.example.com"
    verify_keys:
      "ed25519:auto": "abcdefghijklmnopqrstuvwxyzabcdefghijklmopqr"
  - server_name: "my_other_trusted_server.example.com"
```
Example configuration #2:
```yaml
trusted_key_servers:
  - server_name: "matrix.org"
```
---
### `suppress_key_server_warning`

Set the following to true to disable the warning that is emitted when the
`trusted_key_servers` include 'matrix.org'. See above.

Example configuration:
```yaml
suppress_key_server_warning: true
```
---
### `key_server_signing_keys_path`

The signing keys to use when acting as a trusted key server. If not specified
defaults to the server signing key.

Can contain multiple keys, one per line.

Example configuration:
```yaml
key_server_signing_keys_path: "key_server_signing_keys.key"
```
---
## Single sign-on integration

The following settings can be used to make Synapse use a single sign-on
provider for authentication, instead of its internal password database.

You will probably also want to set the following options to `false` to
disable the regular login/registration flows:
   * [`enable_registration`](#enable_registration)
   * [`password_config.enabled`](#password_config)

---
### `saml2_config`

Enable SAML2 for registration and login. Uses pysaml2. To learn more about pysaml and
to find a full list options for configuring pysaml, read the docs [here](https://pysaml2.readthedocs.io/en/latest/).

At least one of `sp_config` or `config_path` must be set in this section to
enable SAML login. You can either put your entire pysaml config inline using the `sp_config`
option, or you can specify a path to a psyaml config file with the sub-option `config_path`.
This setting has the following sub-options:

* `sp_config`: the configuration for the pysaml2 Service Provider. See pysaml2 docs for format of config.
   Default values will be used for the `entityid` and `service` settings,
   so it is not normally necessary to specify them unless you need to
   override them. Here are a few useful sub-options for configuring pysaml:
   * `metadata`: Point this to the IdP's metadata. You must provide either a local
      file via the `local` attribute or (preferably) a URL via the
      `remote` attribute.
   * `accepted_time_diff: 3`: Allowed clock difference in seconds between the homeserver and IdP.
      Defaults to 0.
   * `service`: By default, the user has to go to our login page first. If you'd like
     to allow IdP-initiated login, set `allow_unsolicited` to true under `sp` in the `service`
     section.
* `config_path`: specify a separate pysaml2 configuration file thusly:
  `config_path: "CONFDIR/sp_conf.py"`
* `saml_session_lifetime`: The lifetime of a SAML session. This defines how long a user has to
   complete the authentication process, if `allow_unsolicited` is unset. The default is 15 minutes.
* `user_mapping_provider`: Using this option, an external module can be provided as a
   custom solution to mapping attributes returned from a saml provider onto a matrix user. The
   `user_mapping_provider` has the following attributes:
  * `module`: The custom module's class.
  * `config`: Custom configuration values for the module. Use the values provided in the
     example if you are using the built-in user_mapping_provider, or provide your own
     config values for a custom class if you are using one. This section will be passed as a Python
     dictionary to the module's `parse_config` method. The built-in provider takes the following two
     options:
      * `mxid_source_attribute`: The SAML attribute (after mapping via the attribute maps) to use
          to derive the Matrix ID from. It is 'uid' by default. Note: This used to be configured by the
          `saml2_config.mxid_source_attribute option`. If that is still defined, its value will be used instead.
      * `mxid_mapping`: The mapping system to use for mapping the saml attribute onto a
         matrix ID. Options include: `hexencode` (which maps unpermitted characters to '=xx')
         and `dotreplace` (which replaces unpermitted characters with '.').
         The default is `hexencode`. Note: This used to be configured by the
         `saml2_config.mxid_mapping option`. If that is still defined, its value will be used instead.
* `grandfathered_mxid_source_attribute`: In previous versions of synapse, the mapping from SAML attribute to
   MXID was always calculated dynamically rather than stored in a table. For backwards- compatibility, we will look for `user_ids`
   matching such a pattern before creating a new account. This setting controls the SAML attribute which will be used for this
   backwards-compatibility lookup. Typically it should be 'uid', but if the attribute maps are changed, it may be necessary to change it.
   The default is 'uid'.
* `attribute_requirements`: It is possible to configure Synapse to only allow logins if SAML attributes
    match particular values. The requirements can be listed under
   `attribute_requirements` as shown in the example. All of the listed attributes must
    match for the login to be permitted.
* `idp_entityid`: If the metadata XML contains multiple IdP entities then the `idp_entityid`
   option must be set to the entity to redirect users to.
   Most deployments only have a single IdP entity and so should omit this option.


Once SAML support is enabled, a metadata file will be exposed at
`https://<server>:<port>/_synapse/client/saml2/metadata.xml`, which you may be able to
use to configure your SAML IdP with. Alternatively, you can manually configure
the IdP to use an ACS location of
`https://<server>:<port>/_synapse/client/saml2/authn_response`.

Example configuration:
```yaml
saml2_config:
  sp_config:
    metadata:
      local: ["saml2/idp.xml"]
      remote:
        - url: https://our_idp/metadata.xml
    accepted_time_diff: 3

    service:
      sp:
        allow_unsolicited: true

    # The examples below are just used to generate our metadata xml, and you
    # may well not need them, depending on your setup. Alternatively you
    # may need a whole lot more detail - see the pysaml2 docs!
    description: ["My awesome SP", "en"]
    name: ["Test SP", "en"]

    ui_info:
      display_name:
        - lang: en
          text: "Display Name is the descriptive name of your service."
      description:
        - lang: en
          text: "Description should be a short paragraph explaining the purpose of the service."
      information_url:
        - lang: en
          text: "https://example.com/terms-of-service"
      privacy_statement_url:
        - lang: en
          text: "https://example.com/privacy-policy"
      keywords:
        - lang: en
          text: ["Matrix", "Element"]
      logo:
        - lang: en
          text: "https://example.com/logo.svg"
          width: "200"
          height: "80"

    organization:
      name: Example com
      display_name:
        - ["Example co", "en"]
      url: "http://example.com"

    contact_person:
      - given_name: Bob
        sur_name: "the Sysadmin"
        email_address": ["admin@example.com"]
        contact_type": technical

  saml_session_lifetime: 5m

  user_mapping_provider:
    # Below options are intended for the built-in provider, they should be
    # changed if using a custom module.
    config:
      mxid_source_attribute: displayName
      mxid_mapping: dotreplace

  grandfathered_mxid_source_attribute: upn

  attribute_requirements:
    - attribute: userGroup
      value: "staff"
    - attribute: department
      value: "sales"

  idp_entityid: 'https://our_idp/entityid'
```
---
### `oidc_providers`

List of OpenID Connect (OIDC) / OAuth 2.0 identity providers, for registration
and login. See [here](../../openid.md)
for information on how to configure these options.

For backwards compatibility, it is also possible to configure a single OIDC
provider via an `oidc_config` setting. This is now deprecated and admins are
advised to migrate to the `oidc_providers` format. (When doing that migration,
use `oidc` for the `idp_id` to ensure that existing users continue to be