|
Программирование >> Oracle
Многоуровневая аутентификация Многоуровневой (n-tier), или промежуточной, аутентификацией называется регистрация программного обеспечения промежуточного уровня от своего имени для выполнения в базе данных каких-либо действий по поручению пользователя. Это позволяет создавать промежуточные приложения, использующие собственную схему аутентификации, например, с помощью сертификатов X509 или другого процесса однократной регистрации и регистрироваться от имени пользователя, не зная его пароля в базе данных. Хотя регистрация выполнена не от имени пользователя, а от имени промежуточного ПО, для базы данных он зарегистрирован. В этой главе мы рассмотрим многоуровневую аутентификацию и использование этой новой возможности Oracle 8i в приложениях. В частности: будут представлены возможности и рассмотрено их использование в приложениях; разработана программа на основе средств библиотеки OCI, которая позволит ис- пользовать промежуточную аутентификацию для регистрации в базе данных; описан оператор ALTER USER, позволяющий использовать промежуточную аутентификацию в базе данных; рассмотрена возможность отслеживания действий, выполняемых от имени про- межуточной учетной записи. 1490 Глава 22 В версии Oracle 8i многоуровневую аутентификацию можно использовать только в программах на основе библиотеки Oracle Call interface (OCI), написанных на языках С или С + + . В Oracle 9i многоуровневая аутентификация будет поддерживаться также интерфейсом JDBC, что существенно расширит ее возможности. Когда использовать многоуровневую аутентификацию? Во времена централизованных и клиент-серверных систем аутентификация была простой. Клиент (приложение) запрашивал у пользователя реквизиты (имя пользователя и пароль) и передавал их серверу базы данных. Сервер проверял эти реквизиты и, если все было правильно, клиент подключался к серверу: Теперь у нас есть Web и, как следствие, многоуровневая архитектура, когда, например, клиент (браузер) предоставляет свои реквизиты промежуточному серверу приложений, на котором выполняются компоненты JavaServer Page (JSP), обращающиеся к CORBA-объекту, который, в свою очередь, взаимодействует с базой данных. Реквизиты, передаваемые ПО промежуточного уровня, могут совпадать или не совпадать с именем пользователя и паролем, использовавшимся во времена клиент-серверной архитектуры, - это могут быть реквизиты, разрешающие доступ к службе каталогов (directory service), чтобы ПО промежуточного уровня могло выяснить, кто подключается и какими привилегиями доступа. Это могут быть реквизиты в виде сертификата X.509, включающего идентификационную информацию и привилегии. В любом случае ПО промежуточного уровня необязательно использует эти реквизиты для регистрации пользователя в базе данных. Клиент больше не взаимодействует с базой данных непосредственно; между ними есть один, два или более промежуточных уровней. Можно, правда, заставить пользователя передавать регистрационное имя и пароль компонентам JSP, которые будут передавать их CORBA-объекту, а тот - серверу базы данных, но это не позволит использовать другие технологии и механизмы аутентификации, в особенности механизмы однократной регистрации. Рассмотрим следующий пример - достаточно типичное современное Web-приложение: Многоуровневая аутентификация 1491 Клиент представляет собой Web-браузер, отображающий HTML-страницы и обращающийся к Web-серверу/серверу приложений по протоколу HTTP (1). Само приложение находится на Web-сервере/сервере приложений, например, в виде Java-сервлета, модуля сервера Apache и т.д. На представленной выше схеме промежуточный сервер использует службу каталогов (directory service), доступную по протоколу LDAP, которой и передаются предоставленные пользователем реквизиты (2). Служба каталогов используется как средство аутентификации сеанса браузера. Если аутентификация прошла успешно, сервер приложений получает соответствующее уведомление (3) и, наконец, подключается к одной из нескольких баз данных (4) для получения данных и обработки транзакций. Реквизиты , передаваемые из браузера серверу приложений на шаге (1), могут быть разного вида - имя пользователя/пароль, ключ с сервера однократной регистрации, некий цифровой сертификат - все; что угодно. Имя пользователя базы данных и его пароль, как правило, не передается. Проблема, конечно же, в том, что серверу приложений необходимо имя пользователя базы данных и пароль для аутентификации пользователя в используемой базе дан-н1х. Более того, комбинации имя пользователя/пароль в каждом случае будут разными. В рассмотренном выше примере имеется четыре базы данных: база данных ошибок, в которой надо регистрироваться, скажем, как TKYTE; база данных затрат, в которой надо регистрироваться как TKYTE US; база данных планировщика, в которой надо регистрироваться как WEBSTKTE; и так далее... Подумайте: сколько у вас имен пользователей и паролей в разных базах данных? Я могу вспомнить не меньше 15. Более того, хотя имена пользователей в базах данных я никогда не меняю, пароли изменяются достаточно часто. Правда, хорошо б1ло бы аутен-
|
© 2006 - 2025 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки. |