Как настроить сквозную аутентификацию в WebSphere Application Server, z/OS и DB2

По умолчанию команды операционной системы из приложений, развернутых на сервере WebSphere Application Server for z/OS, выполняются от имени пользователя, под которым запущен servant. Под этим же пользователем осуществляется соединение с базами данных, например DB2 или IMS по JDBC Type 2. Но можно настроить сервер приложений таким образом, чтобы обеспечить сквозную аутентификацию: пользователь вашего приложения аутентифицируется на сервере и под этим же именем соединяется с базой данных и выполняет команды в операционной системы: создает файлы в USS (например с логами), работает с наборами данных, а так же запускает на выполнение пакетные задания (JOB'ы).

Процесс сквозной аутентификации

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

Введенные данные проверяются с помощью сервера защиты z/OS (IBM предлагает продукт Resource Access Control Facility (RACF)) и если они верны, то открывается запрошенная страница.

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

И под ним же будут выполняться запросы в СУБД DB2: см результат выполнения запроса SELECT CURRENT SQLID FROM SYSIBM.SYSDUMMY1: ROOT.



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

В консоли администрирования сервера приложений WebSphere Application Server for z/OS на странице Security -> Global Security -> z/OS Security Options расположены две опции: Enable application server and z/OS thread identity synchronization, отвечающая за передачу идентификатора пользователя в операционную систему, и Enable the connection manager RunAs thread identity, отвечающая за работу менеджера подключений.

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

Настройка сервера защиты z/OS

Далее необходимо настроить требуемые права доступа в сервере защиты z/OS, например в IBM RACF. Администратор безопасности должен выбрать один из двух вариантов:

а) дать права на сквозную аутентификацию всем пользователям.


RDEFINE FACILITY BBO.SYNC.<cell short name>.<cluster short name> UACC(NONE)
PERMIT BBO.SYNC.<cell short name>.<cluster short name> CLASS(FACILITY) ID(<CR user ID>) ACC (CONTROL)
SETROPTS RACLIST(FACILITY) GENERIC(FACILITY) REFRESH


б) дать права на сквозную аутентификацию только выбранным пользователям.


RDEFINE FACILITY BBO.SYNC.<cell short name>.<cluster short name> UACC(NONE)
PERMIT BBO.SYNC.<cell short name>.<cluster short name> CLASS(FACILITY) ID(<CR user ID>) ACC(READ)

RDEFINE SURROGAT BBO.SYNC.<Run-As user ID> UACC(NONE)
PERMIT BBO.SYNC.<Run-As user ID> CLASS(SURROGAT) ID(<SR user ID>) ACC(READ)

SETROPTS RACLIST(FACILITY) GENERIC(FACILITY) REFRESH
SETROPTS RACLIST(SURROGAT) GENERIC(SURROGAT) REFRESH


(Для каждого пользователя необходимо определить свой профиль в классе SURROGAT, при этом следует быть внимательными: права на профиль в классе FACILITY выдаются пользователю, под которым запущен control region экземпляра сервера приложений, а в классе SURROGAT - пользователю, под которым запущен servant. Run-As user - пользователь, под которым осуществляется аутентификация в приложении.)

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

Настройка приложения для передачи идентификатора пользователя в z/OS

После внесенных изменений начинает работать сквозная аутентификация WebSphere Application Server for z/OS -> DB2, однако для передачи идентификатора пользователя в операционную систему необходимо в окружении приложения выставить свойство com.ibm.websphere.security.SyncToOSThread в значение true. Для этого в дескриптор развертывания web.xml необходимо добавить следующие строки:

<env-entry>
    <env-entry-name>com.ibm.websphere.security.SyncToOSThread</env-entry-name> 
    <env-entry-type>java.lang.Boolean</env-entry-type> 
    <env-entry-value>true</env-entry-value> 
</env-entry>

Выводы

Сквозная аутентификация - еще один путь к защите ваших данных и приложений. В таком важном деле как безопасность не стоит полагаться только на защиту периметра, дескать у меня сервер скрыт за DMZ и бояться нечего. Есть чего. С информацией работают люди, а каждый человек может иметь свои собственные интересы, к тому же еще и меняющиеся со временем. Подумайте, прежде чем дать пользователю, под которым работает адресное пространство вашего сервера приложений, доступ к данным десятков, сотен или тысяч пользователей, работающих с приложениями, развернутыми на этом сервере.

Данные соображения справедливы так же и для корпоративной базы данных. Обычно сервер приложений настраивают таким образом, чтобы он подключался к корпоративной базе данных под каким-то "супер"-пользователем, которому доступны все записи, а разгранечение доступа делают на уровне SQL, т.е. к запросам, выполняемым аутентифицированным на сервере пользователем, в коде приложения добавляют предикаты (самый примитивный случай: and owner = ?). При этом ваши данные остаются беззащитными перед тем "супер"-пользователем, из под которого сервер подключается к СУБД. Использование сквозной аутентификации позволяет устранить и эту проблему с безопасностью.

Понравилось сообщение - подпишитесь на блог