Безопасность CMS Studio

В этой статье вы узнаете, как настроить параметры безопасности для CMS Studio.

Аутентификация

По умолчанию CMS Studio аутентифицирует пользователей через свою внутреннюю базу данных. Однако DC CMS можно настроить на использование внешних методов аутентификации, таких как Lightweight Directory Access Protocol (LDAP), Security Assertion Markup Language (SAML) или любое решение Single-Sign-On (SSO), которое предоставляет заголовки для подтверждения успешной аутентификации.

DC CMS поддерживает следующие средства обеспечения безопасности для доступа к репозиторию:

Studio SAML Security: доступно только в версиях Enterprise
Аутентификация на основе заголовков (Header-Based Authentication): доступно только в версиях Enterprise
LDAP: пользователи импортируются из LDAP в базу данных; доступно только в версиях Enterprise
Внутренняя база данных: пользователи хранятся непосредственно в базе данных

При использовании внешнего метода аутентификации учетные записи пользователей создаются во внутренней базе данных при их первом успешном входе, используя атрибуты из полученных ответов. Любые пользователи, добавленные во внутреннюю базу данных после их первоначального входа через внешнюю аутентификацию, будут помечены как "Управляемые внешне".

Настройка Цепочки Аутентификации

DC CMS поддерживает несколько поставщиков безопасности и позволяет настраивать несколько поставщиков аутентификации, которые будут обрабатываться последовательно до тех пор, пока пользователь не пройдёт аутентификацию и не получит доступ к системе. В случае неудачи аутентификации пользователю будет возвращён код ошибки HTTP 401 Unauthorized, который означает, что доступ запрещён.Такая настройка позволяет CMS Studio управлять несколькими поставщиками безопасности так, как если бы это была одна система аутентификации.

Вот типы поставщиков аутентификации, которые могут быть включены в цепочку:

Заголовки
LDAP
Внутренняя база данных

Обратите внимание, что аутентификация SAML2 не может быть включена в цепочку, так как она работает независимо.

Для настройки цепочки аутентификации откройте файл studio-config-override.yaml, расположенный в CMS_HOME/bin/apache-tomcat/shared/classes/cms/studio/extension. Кроме того, вы можете получить доступ к этому файлу через раздел Глобальная конфигурация в главном меню CMS Studio.

Вот пример конфигурации с четырьмя поставщиками аутентификации: (1) Аутентификация на основе заголовков, (2) LDAP1, (3) LDAP2 и (4) Внутренняя база данных:


       # Studio authentication chain configuration
  studio.authentication.chain:
  # Authentication provider type
  - provider: HEADERS
  # Authentication via headers enabled
    enabled: true
    # Authentication header for secure key
    secureKeyHeader: secure_key
    # Authentication headers secure key that is expected to match secure key value from headers
    # Typically this is placed in the header by the authentication agent
    secureKeyHeaderValue: secure
    # Authentication header for username
    usernameHeader: username
    # Authentication header for first name
    firstNameHeader: firstname
    # Authentication header for last name
    lastNameHeader: lastname
    # Authentication header for email
    emailHeader: email
    # Authentication header for groups: comma separated list of groups
    #   Example:
    #   site_author,site_xyz_developer
    groupsHeader: groups
    # Enable/disable logout for headers authenticated users (SSO)
    # logoutEnabled: false
    # If logout is enabled for headers authenticated users (SSO), set the endpoint of the SP or IdP logout, which should
    # be called after local logout. The {baseUrl} macro is provided so that the browser is redirected back to Studio
    # after logout (https://STUDIO_SERVER:STUDIO_PORT/studio)
    # logoutUrl: /YOUR_DOMAIN/logout?ReturnTo={baseUrl}
  # Authentication provider type
  - provider: LDAP
    # Authentication via LDAP enabled
    enabled: false
    # LDAP Server url
    ldapUrl: ldap://localhost:389
    # LDAP bind DN (user)
    ldapUsername: cn=Manager,dc=my-domain,dc=com
    # LDAP bind password
    ldapPassword: secret
    # LDAP base context (directory root)
    ldapBaseContext: dc=my-domain,dc=com
    # LDAP username attribute
    usernameLdapAttribute: uid
    # LDAP first name attribute
    firstNameLdapAttribute: cn
    # LDAP last name attribute
    lastNameLdapAttribute: sn
    # Authentication header for email
    emailLdapAttribute: mail
    # LDAP groups attribute
    groupNameLdapAttribute: cmsGroup
    # LDAP groups attribute name regex
    groupNameLdapAttributeRegex: .*
    # LDAP groups attribute match index
    groupNameLdapAttributeMatchIndex: 0
  # Authentication provider type
  - provider: LDAP
    # Authentication via LDAP enabled
    enabled: false
    # LDAP Server url
    ldapUrl: ldap://localhost:390
    # LDAP bind DN (user)
    ldapUsername: cn=Manager,dc=my-domain,dc=com
    # LDAP bind password
    ldapPassword: secret
    # LDAP base context (directory root)
    ldapBaseContext: dc=my-domain,dc=com
    # LDAP username attribute
    usernameLdapAttribute: uid
    # LDAP first name attribute
    firstNameLdapAttribute: cn
    # LDAP last name attribute
    lastNameLdapAttribute: sn
    # Authentication header for email
    emailLdapAttribute: mail
    # LDAP groups attribute
    groupNameLdapAttribute: cmsGroup
    # LDAP groups attribute name regex
    groupNameLdapAttributeRegex: .*
    # LDAP groups attribute match index
    groupNameLdapAttributeMatchIndex: 0
  # Authentication provider type
  - provider: DB
    # Authentication via DB enabled
    enabled: true

В описанной конфигурации, когда пользователь пытается аутентифицироваться, его учетные данные сначала отправляются поставщику аутентификации на основе заголовков. Если этот поставщик успешно аутентифицирует пользователя, процесс завершается, и пользователю предоставляется доступ. Если аутентификация не удалась, учетные данные передаются в LDAP1. Если LDAP1 успешно аутентифицирует пользователя, процесс завершается; если нет, учетные данные передаются в LDAP2. Если аутентификация успешна, процесс завершается; в противном случае учетные данные передаются последнему поставщику в цепочке — внутренней базе данных. Внутренняя база данных определяет, успешна ли аутентификация, или должно быть отправлено сообщение HTTP 401 Unauthorized.

Настройка SAML2

DC Studio можно настроить на поддержку единого входа SAML2 без использования каких-либо дополнительных плагинов.

Требования

Корректно настроенный поставщик идентификационных данных (IdP), совместимый с SAML2; конкретные детали этой настройки не описываются в данной статье.
Приватный ключ и сертификат, которые можно создать с помощью следующей команды:


      openssl req -newkey rsa:2048 -nodes -keyout rp-private.key -x509 -days 365 -out rp-certificate.crt

Обратите внимание на следующие параметры, использованные при создании ключа и сертификата, так как они понадобятся для настройки CMS Studio:

keyout: это значение должно быть использовано для свойства studio.security.saml.rp.privateKey.location
out: это значение должно быть использовано для свойства studio.security.saml.rp.certificate.location

Настройка

Чтобы настроить SAML2, нам необходимо включить безопасность SAML, после чего мы настроим необходимые свойства конфигурации SAML.

Чтобы включить безопасность SAML, раскомментируйте строку export SPRING_PROFILES_ACTIVE=cms.studio.samlSecurity:


      # -------------------- Spring Profiles --------------------
...
# Uncomment to enable CMS Studio SAML2 security
export SPRING_PROFILES_ACTIVE=cms.studio.samlSecurity
# For multiple active spring profiles, create comma separated list

Далее мы настроим свойства конфигурации SAML. Перейдите в CMS_HOME/bin/apache-tomcat/shared/classes/cms/studio/extension и добавьте/раскомментируйте следующие строки в studio-config-override.yaml (разумеется, можно вносить любые соответствующие изменения конфигурации в соответствии с вашей системой):


      ###############################################################
##               SAML Security                               ##
###############################################################
# SAML attribute name for email
# studio.security.saml.attributeName.email: email
# SAML attribute name for first name
# studio.security.saml.attributeName.firstName: givenName
# SAML attribute name for last name
# studio.security.saml.attributeName.lastName: surname
# SAML attribute name for group
# studio.security.saml.attributeName.group: Role
###############################################################
##         SAML Security Relying Party (SP) configuration    ##
###############################################################
# {baseUrl} and {registrationId} are pre-defined macros and should not be modified
# SAML relying party (SP) registration ID. {registrationId} macro will be replaced with this value
# studio.security.saml.rp.registration.id: SSO
# SAML relying party (SP) entity ID
# studio.security.saml.rp.entity.id: "{baseUrl}/saml/metadata"
# SAML relying party (SP) login processing url. Must end with {registrationId}
# studio.security.saml.rp.loginProcessingUrl: "/saml/{registrationId}"
# SAML relying party (SP) assertion consumer service location. Must end with {registrationId}
# studio.security.saml.rp.assertion.consumer.service.location: "{baseUrl}/saml/{registrationId}"
# SAML relying party (SP) assertion consumer service biding (POST or REDIRECT)
# studio.security.saml.rp.assertion.consumer.service.binding: POST
# SAML logout URL without prefix /studio
# studio.security.saml.rp.logoutUrl: /saml/logout
# SAML relying party (SP) single logout service location
# studio.security.saml.rp.logout.service.location: "{baseUrl}/saml/logout"
# SAML relying party (SP) logout service binding (POST or REDIRECT)
# studio.security.saml.rp.logout.service.binding: POST
# SAML relying party (SP) metadata endpoint
# studio.security.saml.rp.metadata.endpoint: /saml/metadata
# SAML relying party (SP) private key location
# studio.security.saml.rp.privateKey.location: classpath:cms/studio/extension/saml/rp-private.key
# SAML relying party (SP) certificate location
# studio.security.saml.rp.certificate.location: classpath:cms/studio/extension/saml/rp-certificate.crt
###############################################################
##      SAML Security Asserting Party (IdP) configuration    ##
###############################################################
# SAML asserting party (IdP) entity ID:
# studio.security.saml.ap.entityId: https://ap.example.org/ap-entity-id
# SAML asserting party (IdP) single sign on service location
# studio.security.saml.ap.single.signOn.service.location: https://ap.example.org/sso/saml
# SAML asserting party (IdP) single sign on service binding (POST or REDIRECT)
# studio.security.saml.ap.single.signOn.service.binding: POST
# SAML asserting party (IdP) logout service location
# studio.security.saml.ap.single.logout.service.location: https://ap.example.org/slo/saml
# SAML asserting party (IdP) logout service binding (POST or REDIRECT)
# studio.security.saml.ap.single.logout.service.binding: POST
# SAML asserting party (IdP) want authn request signed
# studio.security.saml.ap.want.authn.request.signed: false
# SAML asserting party (IdP) certificate location
# studio.security.saml.ap.certificate.location: classpath:cms/studio/extension/saml/idp-certificate.crt
###############################################################
##            SAML Security other configuration              ##
###############################################################
# SAML Web SSO profile options: authenticate the user silently
# studio.security.saml.webSSOProfileOptions.passive: false
# SAML Web SSO profile options: force user to re-authenticate
# studio.security.saml.webSSOProfileOptions.forceAuthn: false

где:

studio.security.saml.enabled: указывает, активна ли аутентификация SAML2
Для корректной работы CMS Studio от IdP требуются следующие атрибуты:
- - studio.security.saml.attributeName.email
  - studio.security.saml.attributeName.firstName
  - studio.security.saml.attributeName.lastName
  - studio.security.saml.attributeName.group
studio.security.saml.rp.privateKey.location: путь к закрытому ключу для стороннего сервиса (SP) в classpath
studio.security.saml.rp.certificate.location: путь к сертификату для стороннего сервиса (SP) в classpath
studio.security.saml.ap.entityId: идентификатор объекта утверждающей стороны (IdP)
studio.security.saml.ap.single.signOn.service.location: URL для единого входа для утверждающей стороны (IdP)
studio.security.saml.ap.single.logout.service.location: URL для единого выхода для утверждающей стороны (IdP)
studio.security.saml.ap.certificate.location: путь к сертификату для утверждающей стороны (IdP) в classpath
studio.security.saml.webSSOProfileOptions.passive: указывает, аутентифицируется ли пользователь без непосредственного участия с его стороны
studio.security.saml.webSSOProfileOptions.forceAuthn: указывает, будет ли пользователь вынужден повторно пройти аутентификацию

Classpath находится по пути CMS_HOME/bin/apache-tomcat/shared/classes. Например, закрытый ключ стороннего сервиса можно найти по пути CMS_HOME/bin/apache-tomcat/shared/classes/cms/studio/extension/saml.


      # SAML relying party (SP) private key location
studio.security.saml.rp.privateKey.location: classpath:cms/studio/extension/saml/rp-private.key

Перезапустите authoring-установку после настройки, описанной выше.

Настройка аутентификации на основе заголовков

CMS Studio может работать без проблем с любой системой аутентификации, которая использует пользовательские HTTP-заголовки для предоставления данных, необходимых для аутентификации пользователя.

Настройка CMS Studio для аутентификации на основе заголовков

Перейдите в вашу authoring-установку по пути CMS_HOME/bin/apache-tomcat/shared/classes/cms/studio/extension и добавьте следующие строки в файл studio-config-override.yaml (обязательно скорректируйте настройки в соответствии с требованиями вашей системы):


      # Studio authentication chain configuration
# studio.authentication.chain:
  # Authentication provider type
  # - provider: HEADERS
    # Authentication via headers enabled
    # enabled: true
    # Authentication header for secure key
    # secureKeyHeader: secure_key
    # Authentication headers secure key that is expected to match secure key value from headers
    # Typically this is placed in the header by the authentication agent
    # secureKeyHeaderValue: secure
    # Authentication header for username
    # usernameHeader: username
    # Authentication header for first name
    # firstNameHeader: firstname
    # Authentication header for last name
    # lastNameHeader: lastname
    # Authentication header for email
    # emailHeader: email
    # Authentication header for groups: comma separated list of sites and groups
    #   Example:
    #   site_author,site_xyz_developer
    # groupsHeader: groups
    # (Optional) All authentication header values are in this JWT header's claims.
    # jwtAuthTokenHeader: x-cms-oidc-data
    # Enable/disable logout for headers authenticated users (SSO)
    # logoutEnabled: false
    # If logout is enabled for headers authenticated users (SSO), set the endpoint of the SP or IdP logout, which should
    # be called after local logout. The {baseUrl} macro is provided so that the browser is redirected back to Studio
    # after logout (https://STUDIO_SERVER:STUDIO_PORT/studio)
    # logoutUrl: /YOUR_DOMAIN/logout?ReturnTo={baseUrl}

Атрибут enabled контролирует, активна ли аутентификация через заголовки; убедитесь, что он установлен в значение true для аутентификации на основе заголовков.

Атрибут secure_key является секретным ключом, который передается между агентом аутентификации и CMS Studio через этот заголовок. Атрибут secure_key обязателен, и аутентификация на основе заголовков не будет выполнена, если secure_key, отправленный в CMS Studio, не совпадает с настроенным значением.

После проверки secure_key, CMS Studio затем будет искать субъект (principal). Информация о субъекте может быть предоставлена в одном из двух форматов:

Коллекция отдельных заголовков, указывающих атрибуты субъекта, такие как имя пользователя, имя, фамилия, электронная почта и группы.
Набор атрибутов субъекта, заключенный в JWT, как это определено x-cms-oidc-data.

В зависимости от вашего агента аутентификации настройте CMS Studio на распознавание либо отдельных атрибутов, либо JWT.

Настройка выхода из системы

Кнопка "Выйти" по умолчанию отключена или скрыта, когда активирована аутентификация на основе заголовков.

Чтобы позволить пользователям, вошедшим с использованием аутентификации на основе заголовков, получить доступ к опции "Выйти", измените следующие строки в вашем файле studio-config-override.yaml (при необходимости подстроив конфигурации для вашей системы):


      # Enable/disable logout for headers authenticated users (SSO)
# logoutEnabled: false
# If logout is enabled for headers authenticated users (SSO), set the endpoint of the SP or IdP logout, which should
# be called after local logout. The {baseUrl} macro is provided so that the browser is redirected back to Studio
# after logout (https://STUDIO_SERVER:STUDIO_PORT/studio)
# logoutUrl: /YOUR_DOMAIN/logout?ReturnTo={baseUrl}

Настройка LDAP аутентификации

Чтобы настроить аутентификацию по протоколу LDAP, в вашей authoring-установке перейдите в CMS_HOME/bin/apache-tomcat/shared/classes/cms/studio/extension и раскомментируйте следующие строки в файле studio-config-override.yaml:

# Studio authentication chain configuration

studio.authentication.chain:

# Authentication provider type

- provider: LDAP

# Authentication via LDAP enabled

enabled: true

# LDAP Server url

ldapUrl: ldap://localhost:389

# LDAP bind DN (user)

ldapUsername: cn=Manager,dc=my-domain,dc=com

# LDAP bind password

ldapPassword: secret

# LDAP base context (directory root)

ldapBaseContext: dc=my-domain,dc=com

# LDAP username attribute

usernameLdapAttribute: uid

# LDAP first name attribute

firstNameLdapAttribute: cn

# LDAP last name attribute

lastNameLdapAttribute: sn

# LDAP email attribute

emailLdapAttribute: mail

# LDAP groups attribute

groupNameLdapAttribute: cmsGroup

# LDAP groups attribute name regex

groupNameLdapAttributeRegex: .*

# LDAP groups attribute match index

groupNameLdapAttributeMatchIndex: 0

Вот некоторые ключевые моменты по указанным выше свойствам:

enabled: этот параметр включает или отключает аутентификацию LDAP. Чтобы использовать аутентификацию LDAP, убедитесь, что он установлен в значение true.
serverUrl: это URL, по которому доступен LDAP-сервер для обработки запросов.
bindDN и bindPassword: эти данные представляют учетные данные, необходимые для начального подключения к LDAP-серверу.
baseContext: это указывает корень дерева LDAP-директории, где можно найти записи пользователей.
username, firstName, lastName и email: эти атрибуты являются стандартными для пользователей.
groupName: это указывает группы, к которым принадлежит пользователь, и может включать несколько значений. Вы можете использовать регулярное выражение для извлечения имени группы пользователя.

Когда пользователь пытается войти в систему и его нет в базе данных, CMS Studio запросит LDAP-сервер. Если будет найдено совпадение, пользователь будет создан в базе данных с атрибутами LDAP и добавлен в указанные группы LDAP.

Обратите внимание, что все атрибуты, указанные в конфигурации, должны присутствовать в атрибутах пользователя LDAP, чтобы CMS Studio могла аутентифицировать пользователя. Если какой-либо атрибут отсутствует, на экране входа будет показано сообщение об ошибке: "Произошла системная ошибка. Пожалуйста, подождите несколько минут или свяжитесь с администратором." Проверьте журнал Tomcat, чтобы определить, какой атрибут отсутствует. Вот пример записи из журнала:


      [WARN] 2017-10-11 12:42:57,487 [http-nio-8080-exec-2] [security.DbWithLdapExtensionSecurityProvider] | No LDAP attribute cmsGroup found for username jbloggs

Убедитесь, что хотя бы один атрибут groupName из LDAP-пользователя присутствует в CMS Studio и имеет настроенные соответствующие роли и разрешения. Если в CMS Studio не настроен атрибут groupName с ролями и разрешениями, системный администратор должен назначить роль хотя бы одной группе в CMS Studio. В противном случае пользователи могут столкнуться с уведомлением "Недопустимый сайт" при попытке предварительного просмотра сайта или доступа к панели управления на экране "Сайты".

Чтобы назначить роль группе, пожалуйста, следуйте руководству по сопоставлению ролей. Чтобы назначить права доступа для роли, пожалуйста, ознакомьтесь с разделом "Сопоставление разрешений".

Авторизация

Сопоставление ролей

Подробнее о понятии и настройке ролей в CMS Studio можно узнать здесь.

Сопоставление разрешений

Подробнее о понятии и настройке разрешений в CMS Studio можно узнать здесь.

Дополнительные настройки безопасности

Требования к паролю для CMS Studio

Валидация требований к паролю предоставляет администраторам возможность устанавливать правила, гарантирующие, что пользователи создают пароли в соответствии с политикой безопасности паролей организации.

В CMS Studio управление надежностью пароля осуществляется с использованием технологии zxcvbn.

Параметры надежности пароля отображаются пользователям во время сброса пароля или создания учетной записи.

Чтобы настроить параметры надежности пароля, нажмите на значок меню навигации в правом верхнем углу экрана, затем выберите Глобальная конфигурация. Прокрутите вниз до раздела Security и измените значение studio.security.passwordRequirements.minimumComplexity на желаемую минимальную сложность пароля.


      # Password requirements minimum complexity
# This is based on https://github.com/dropbox/zxcvbn
# The minimum complexity corresponds to the password score
# You can try this out here https://lowe.github.io/tryzxcvbn/
#  score      # Integer from 0-4 (useful for implementing a strength bar)
#  0 # too guessable: risky password. (guesses < 10^3)
#  1 # very guessable: protection from throttled online attacks. (guesses < 10^6)
#  2 # somewhat guessable: protection from unthrottled online attacks. (guesses < 10^8)
#  3 # safely unguessable: moderate protection from offline slow-hash scenario. (guesses < 10^10)
#  4 # very unguessable: strong protection from offline slow-hash scenario. (guesses >= 10^10)
# The default value is 3
studio.security.passwordRequirements.minimumComplexity: 3

Минимальная сложность пароля по умолчанию в CMS Studio установлена на 3.

Случайная генерация пароля администратора

DC CMS предоставляет возможность случайной генерации пароля администратора во время первоначальной установки. Чтобы реализовать это, перед первым запуском DC CMS перейдите по пути CMS_HOME/bin/apache-tomcat/shared/classes/cms/studio/extension/ и отредактируйте файл studio-config-override.yaml, включив в него следующую конфигурацию:


      ##################################################
##                   Security                   ##
##################################################
# Enable random admin password generation
studio.db.initializer.randomAdminPassword.enabled: false
# Random admin password length
studio.db.initializer.randomAdminPassword.length: 16
# Random admin password allowed chars
studio.db.initializer.randomAdminPassword.chars: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*_=+-/

Чтобы включить случайную генерацию пароля администратора, просто установите studio.db.initializer.randomAdminPassword.enabled в значение true и укажите желаемую длину пароля и допустимые символы для пароля. Сохраните файл после внесения изменений и запустите DC CMS.

Затем вам нужно будет просмотреть логи tomcat и найти следующую строку, чтобы получить сгенерированный случайный пароль для пользователя admin: *** Admin Account Password.

Вот пример сгенерированного пароля для администратора:


      INFO: *** Admin Account Password: "WXOIK$O$yGixio2h" ***

Теперь вы можете войти как пользователь admin, используя случайно сгенерированный пароль, указанный в журнале tomcat.

Тайм-ауты

DC CMS предоставляет возможность настраивать временные интервалы для времени жизни сессии и неактивности сессии.

Время жизни сессии определяет, как долго сессия остается действительным до необходимости повторной аутентификации пользователя.

В то время как время неактивности сессии определяет период неактивности пользователя, после которого требуется повторная аутентификация.

В некоторых случаях некоторые операции внутри DC CMS могут превысить конфигурации времени неактивности сессии пользователя. В таких случаях необходимо отрегулировать время неактивности сессии, чтобы завершение операции не приводило к завершению сессии.

Ниже расположено краткое описание тайм-аутов, доступных в DC CMS:

Название тайм-аута	Значение по умолчанию (в минутах)	Описание
`sessionTimeout`	480	Время жизни сессии в CMS Studio Локация:`CMS_HOME/bin/apache-tomcat/shared/classes/cms/studio/extension/studio-config-override.yaml` Количество времени, в течение которого сеанс действителен, считая с момента входа пользователя в систему. По истечении этого времени сессия будет завершена, даже если пользователь активен.
`inactivityTimeout`	30	Время неактивности сессии Локация:`CMS_HOME/bin/apache-tomcat/shared/classes/cms/studio/extension/studio-config-override.yaml` Количество времени бездействия пользователя, отслеживаемое CMS Studio, по истечении которого пользователю потребуется повторная аутентификация. Не забудьте установить значение `inactivityTimeout` меньше, чем значение `session-timeout` в файле `web.xml`. Время неактивности сеанса, отслеживаемое DC Studio, отличается от времени неактивности сеанса, отслеживаемого Tomcat. Это связано с тем, что есть некоторые вызовы API, которые CMS Studio не отслеживает как активные.
`session-timeout`	30	Время жизни сессии Tomcat Локация:`CMS_HOME/bin/apache-tomcat/webapps/studio/WEB-INF/web.xml` Количество времени бездействия пользователя, отслеживаемое Tomcat, по истечении которого пользователю потребуется повторная аутентификация. Это значение должно быть больше или равно `inactivityTimeout`, поскольку таймаут `inactivityTimeout` может срабатывать раньше этого.

Изменение времени жизни сессии

Перейдите по пути CMS_HOME/bin/apache-tomcat/shared/classes/cms/studio/extension/studio-config-override.yaml и в значении studio.security.sessionTimeout укажите количество времени (в минутах), в течение которого сессия действительна. Например, studio.security.sessionTimeout: 480.

Изменение времени неактивности сессии

Вы можете настроить два тайм-аута для неактивности сессии:

session-timeout в файле web.xml Tomcat: этот таймаут обрабатывает неактивные соединения
inactivityTimeout в файле конфигурации переопределения CMS Studio: этот таймаут применяется к неактивности сеанса Studio

Чтобы изменить таймаут неактивности сеанса, выполните следующие шаги:

Перейдите по пути CMS_HOME/bin/apache-tomcat/shared/classes/cms/studio/extension/studio-config-override.yaml и в значении studio.security.inactivityTimeout укажите желаемое количество времени (в минутах) до истечения сессии пользователя из-за неактивности. Например, studio.security.inactivityTimeout: 30.
Перейдите по пути CMS_HOME/bin/apache-tomcat/webapps/studio/WEB-INF/web.xml и между тегами session-timeout укажите желаемое время существования сессии в минутах.


      <session-config>
  <session-timeout>30</session-timeout>
  <tracking-mode>COOKIE</tracking-mode>
    </session-config>

Убедитесь, что время неактивности сессии CMS Studio, указанное в файле studio-config-override.yaml в параметре inactivityTimeout, меньше, чем время неактивности сессии Tomcat в файле CMS_HOME/bin/apache-tomcat/webapps/studio/WEB-INF/web.xml.

После настройки этих параметров не забудьте остановить и перезапустить CMS Studio, чтобы изменения вступили в силу.

Конфигурация шифра


      ##################################################
##                   Security                   ##
##################################################
# Time in minutes after which active users will be required to login again
# studio.security.sessionTimeout: 480
# Time in minutes after which inactive users will be required to login again
# studio.security.inactivityTimeout: 30
#
# Salt for encrypting
studio.security.cipher.salt: ${env:CMS_SYSTEM_ENCRYPTION_SALT}
# Key for encrypting
studio.security.cipher.key: ${env:CMS_SYSTEM_ENCRYPTION_KEY}
# The key used for encryption of configuration properties
studio.security.encryption.key: ${env:CMS_ENCRYPTION_KEY}
# The salt used for encryption of configuration properties
studio.security.encryption.salt: ${env:CMS_ENCRYPTION_SALT}
# The path of the folder used for the SSH configuration
studio.security.ssh.config: ${env:CMS_SSH_CONFIG}
# Defines name used for environment specific configuration. It is used for environment overrides in studio. Default value is default.
studio.configuration.environment.active: ${env:CMS_ENVIRONMENT}

Токены доступа

Следующий раздел переопределений конфигурации CMS Studio позволяет вам настроить параметры для токенов доступа CMS Studio. Токены доступа затем можно использовать для вызова REST API CMS Studio.


      ##################################################
##               Access Tokens                  ##
##################################################
# Issuer for the generated access tokens
studio.security.token.issuer: ${env:STUDIO_TOKEN_ISSUER}
# List of accepted issuers for validation of access tokens (separated by commas)
studio.security.token.validIssuers: ${env:STUDIO_TOKEN_VALID_ISSUERS}
# The audience for generation and validation of access tokens (if empty the instance id will be used)
studio.security.token.audience: ${env:STUDIO_TOKEN_AUDIENCE}
# Time in minutes for the expiration of the access tokens
studio.security.token.timeout: ${env:STUDIO_TOKEN_TIMEOUT}
# Password for signing the access tokens (needs to be equal or greater than 512 bits in length)
studio.security.token.password.sign: ${env:STUDIO_TOKEN_SIGN_PASSWORD}
# Password for encrypting the access tokens
studio.security.token.password.encrypt: ${env:STUDIO_TOKEN_ENCRYPT_PASSWORD}
# Name of the cookie to store the refresh token
studio.security.token.cookie.name: ${env:STUDIO_REFRESH_TOKEN_NAME}
# Time in seconds for the expiration of the refresh token cookie
studio.security.token.cookie.maxAge: ${env:STUDIO_REFRESH_TOKEN_MAX_AGE}
# Indicates if the refresh token cookie should be secure (should be true for production environments behind HTTPS)
studio.security.token.cookie.secure: ${env:STUDIO_REFRESH_TOKEN_SECURE}

Связанные статьи

Безопасность DC CMS

Документация для разработчика