Все чаще и чаще разработчикам на СУБД Oracle приходится сталкиваться с необходимостью использования интегрированной/доменной аутентификации пользователей. На данную тему ну очень мало информации в Интернете и тем более на русском языке. Лично я с данной проблемой сталкиваюсь очень часто, т.к. наш заказчик пожелал перейти на данный вид аутентификации, и я решил поделиться опытом и знаниями в этой области.
Для начало хотелось бы рассказать о двух способах настройки Oracle, чтобы подключение к СУБД не требовало имени пользователя и пароля.
1. Использование флага REMOTE_OS_AUTHENT в initorcl.ora
Данный способ является самым простым и общедоступным, но самым не безопасным. Если выставить данный флаг в настройках initorcl.ora (находится он обычно ..\admin\orсl\pfile\, но это больше зависит от версии Oracle), то получить доступ к серверу СУБД будет легко, зная имя пользователя, зарегистрированного на СУБД и параметр OS_AUTHENT_PREFIX (как данный параметр задается, описано в самом конце статьи).
Вот как данный параметр описан в документации Oracle
Также, из документации к Oracle 11.2, известно, что параметр REMOTE_OS_AUTHENT снят с поддержки как небезопасный ( Deprecated ). В этой версии СУБД это означает, что он просто не рекомендуется к использованию, но работает в случае его активации. Нет гарантии, что компания Oracle, как серьезный борец за безопасность своих продуктов, в следующей версии СУБД (или даже релизе) не присвоит этому параметру статус OBSOLETE, а это будет означать, что данный параметр не только не рекомендуется к использованию, но и не будет работать.
Резюмируя выше сказанное, можно понять, что если у Вашего заказчика не серьезные требования по безопасности и местные администраторы СУБД согласятся с данным методом аутентификации, плюс версия СУБД еще поддерживает данный параметр, то можно спользовать аутентификацию и через данный параметр, НО лично я настоятельно при этом советую поменять параметр OS_AUTHENT_PREFIX (значение по умолчанию OPS$ его известно практически каждому, кто более менее серьезно занимается Oracle).
P.S. Пока писал эту часть статьи, наткнулся вот на такую статейку Oracle: Создаем пользователя с аутнетификацией на уровне ОС и парольной аутентификацией, в которой если честно, ни слова про серьезность угрозы безопасности, но зато есть примеры как этот параметр можно установить и создать доменного пользователя.
2. Аутентификация Oracle + по протоколу Kerberos + Activy Directory + IIS + ASP.net приложение
Обращаю внимание на галочку "Integrated Windows authentication", это означает что доменная авторизация у вас будет работать по протоколу Kerberos, который поддерживается только браузером IE.
Права на изменение данных параметров есть только у системных администраторов.
Для IE для пользователей приложения необходимо разрешить передавать доменный пароль:
Для начало хотелось бы рассказать о двух способах настройки Oracle, чтобы подключение к СУБД не требовало имени пользователя и пароля.
1. Использование флага REMOTE_OS_AUTHENT в initorcl.ora
Данный способ является самым простым и общедоступным, но самым не безопасным. Если выставить данный флаг в настройках initorcl.ora (находится он обычно ..\admin\orсl\pfile\, но это больше зависит от версии Oracle), то получить доступ к серверу СУБД будет легко, зная имя пользователя, зарегистрированного на СУБД и параметр OS_AUTHENT_PREFIX (как данный параметр задается, описано в самом конце статьи).
Вот как данный параметр описан в документации Oracle
Исчтоник Oracle database Security FAQWhy are OPS$ accounts a security risk in a client/server environment?
If you allow people to log in with OPS$ accounts from Windows Workstations, you cannot be sure who they really are. With terminals, you can rely on operating system passwords, with Windows, you cannot.
If you set REMOTE_OS_AUTHENT=TRUE in your init.ora file, Oracle assumes that the remote OS has authenticated the user.
If REMOTE_OS_AUTHENT is set to FALSE (recommended), remote users will be unable to connect without a password. IDENTIFIED EXTERNALLY will only be in effect from the local host. Also, if you are using "OPS$" as your prefix, you will be able to log on locally with or without a password, regardless of whether you have identified your ID with a password or defined it to be IDENTIFIED EXTERNALLY.
Также, из документации к Oracle 11.2, известно, что параметр REMOTE_OS_AUTHENT снят с поддержки как небезопасный ( Deprecated ). В этой версии СУБД это означает, что он просто не рекомендуется к использованию, но работает в случае его активации. Нет гарантии, что компания Oracle, как серьезный борец за безопасность своих продуктов, в следующей версии СУБД (или даже релизе) не присвоит этому параметру статус OBSOLETE, а это будет означать, что данный параметр не только не рекомендуется к использованию, но и не будет работать.
Резюмируя выше сказанное, можно понять, что если у Вашего заказчика не серьезные требования по безопасности и местные администраторы СУБД согласятся с данным методом аутентификации, плюс версия СУБД еще поддерживает данный параметр, то можно спользовать аутентификацию и через данный параметр, НО лично я настоятельно при этом советую поменять параметр OS_AUTHENT_PREFIX (значение по умолчанию OPS$ его известно практически каждому, кто более менее серьезно занимается Oracle).
P.S. Пока писал эту часть статьи, наткнулся вот на такую статейку Oracle: Создаем пользователя с аутнетификацией на уровне ОС и парольной аутентификацией, в которой если честно, ни слова про серьезность угрозы безопасности, но зато есть примеры как этот параметр можно установить и создать доменного пользователя.
2. Аутентификация Oracle + по протоколу Kerberos + Activy Directory + IIS + ASP.net приложение
В первую очередь, необходимо уточнить у администраторов СУБД заказчика, куплена ли лицензия у Oracle на дополнительный пакет безопасности, в который входит Kerberos (он стоит денег и не мало, и часто данный пакет не покупают).
Ознакомиться с понятием протокола поможет Wikipedia
Как настраивать в Oracle Kerberos расписывать не будем, т.к. и так доступным языком описано в Oracle® Database Advanced Security Administrator's Guide (ссылку привел для версии 11.2, но и для более ранних найти не проблема).
Лучше приведем примеры как настраивать для этого IIS и ASP.net приложения (для начинающих программистов или просто тех, кто не знает как устроена безопасность советую почитать данную статейку Модель безопасности ASP.NET)
Для доменной авторизации в web.config ASP.net приложения необходимо добавить/изменить строчки
<authentication mode="Windows">
<forms loginUrl="Sys/Login.aspx" />
</authentication>
<authorization>
<deny users="?"/>
</authorization><identity impersonate="true" />Далее настраиваем IIS 6.0
Обращаю внимание на галочку "Integrated Windows authentication", это означает что доменная авторизация у вас будет работать по протоколу Kerberos, который поддерживается только браузером IE.
Для IIS7:
Альтернативный делегации описаны в блоке «Delegation Alternatives»: http://msdn.microsoft.com/ru-ru/library/aa291350(en-us).aspx
и тут
Из статей видно, что у веб-сервера должно бы установлено делегирование <Trust computer for delegation>, а для учетных записей пользователей в AD должен быть сброшен флаг <Account is sensitive and cannot be delegated> (настраивается там же):
Для IE для пользователей приложения необходимо разрешить передавать доменный пароль:
Ну и напоследок, опишем где задается как включается доменная :- Задать префикс пользователям на сервере СУБД в файле ..\admin\orсl\pfile\initorcl.ora (записывается в формате OS_AUTHENT_PREFIX = "VALUE")
- На клиентской части (где стоит IIS) И!!! на сервере СУБД необходимо добавить строчку SQLNET.AUTHENTICATION_SERVICES= (NTS) в файл ..\network\admin\sqlnet.ora
Комментариев нет:
Отправить комментарий